Логика за таблица и показване на резултати

typeface

Registered
Здравейте,

Извинявам се за заглавието, но не можах да измисля как точно да го напиша. Моля някой, който има права ако сметне за нужно да го редактира. Та на въпроса:

Имам проста HTML таблица с 2 колони: хора | цена

На сйта се визуализира така:

Код:
Брой хора | Цена
    1                  $2
    2                  $3
    ..                  ..
    9                  $500
Особеното тук е, че лявата колона "Брой хора" няма да се променя и винаги ще е от 1 до 9. Юзъра ще има право да си променя само цената.

Моля, за помощт при логиката и създаването на таблиците в базата данни. В момента имам таблица "users", която логично държи юзърите.

Предполагам трябва да си направя втора таблица "rates" примерно, която да държи цената. Как би станало, какви колони да съдържа?

В случая трудното ми е как тази колона, която няма да се променят стойностите ще отговаря на другата и как да я вържа да показва данните за съответния потребител.
 
Всеки юзър трябва си има собствено копие на таблицата, която си дал ли?
 
anonimen каза:
Всеки юзър трябва си има собствено копие на таблицата, която си дал ли?
Да, и да може да си променя само цените в колона 'Цена"
 
typeface каза:
anonimen каза:
Всеки юзър трябва си има собствено копие на таблицата, която си дал ли?
Да, и да може да си променя само цените в колона 'Цена"

В rates във всеки запис ще държиш цената за двойка юзър/брой хора.

Т.е. за примерно user 5/8 people ще държиш цена $10.

Вече мисля, че е очевидно - трябват ти три колони. Потребител, брой хора и цена.
Когато потребител 2 редактира цената за 3ма души на 14, в базата ще ъпдейтваш съответния запис:

Код:
UPDATE rates SET price=14 WHERE user_id = 2 AND number_of_people = 3
 
anonimen каза:
Т.е. за примерно user 5/8 people ще държиш цена $10.

Вече мисля, че е очевидно - трябват ти три колони. Потребител, брой хора и цена.

Не съм сигурен, че разбирам. Т.е. предлагаш това?

Код:
user_id     |        number_of_people          |       price
     1                                    1                                    1
     1                                    2                                    10
   ....                                  .......                                ......
     1                                      9                                   100
     2                                      1                                     5
     ...
 
Разбира се аз бих държал само по 1 ст-ст за всеки юзър, като за различен брой хора автоматично ще смятам цената. Защо да държа 10 стойности ако мога да държа 1?
 
anonimen каза:
Разбира се аз бих държал само по 1 ст-ст за всеки юзър, като за различен брой хора автоматично ще смятам цената. Защо да държа 10 стойности ако мога да държа 1?
А това как би станало? В смисъл тя цената няма как да се смята, защото е динамична и юзъра си определя. Няма как да знам че Цена 1 + Цена 2 ще даде Цена 3
 
typeface каза:
anonimen каза:
Разбира се аз бих държал само по 1 ст-ст за всеки юзър, като за различен брой хора автоматично ще смятам цената. Защо да държа 10 стойности ако мога да държа 1?
А това как би станало? В смисъл тя цената няма как да се смята, защото е динамична и юзъра си определя. Няма как да знам че Цена 1 + Цена 2 ще даде Цена 3
T.е. ще караш юзера ръчно да си въвежда всяка стойност по отделно? И така за 10 човека? А ако в последствие решиш да са 30? Или 100?

По-скоро въвежда цена за 1 човек и останалото се смята автоматично. Ако иска да има някакво намаление при повече хора, може да добавиш и такава опция, но да държиш по 10 (или 50) повтарящи се записа за всеки юзер е леко казано излишно.

Не вярвам да имаш потребител, за който 1 човек ще струва 5, а 2ма ще струват 4 примерно.
 
Благодаря за помощта до тук, но явно нещо не успявам да те разбера. Може ли малък пример на структурата?
 
typeface каза:
Благодаря за помощта до тук, но явно нещо не успявам да те разбера. Може ли малък пример на структурата?

Код:
table users
- int id
- каквито полета още ти трябват

table prices
- int user_id 
- int number_of_people
- int price
PRIMARY KEY(user_id, number_of_people) -- по този начин осигуряваш двойките user/NoP да са уникални

Ако ще го правиш само с по 1 стойност per user, няма да ти трябва отделна таблица, просто записваш единствената цена в ново поле в users таблицата. Т.е. за всеки юзър в таблицата users имаш поле price, в което ще записваш цената за 1 човек, избрана от съответния юзър.
 
Tоест така:
6868.jpg


За рейтовете/цената, а понеже брой хора е винаги еднаква стойност може и да не я вкарвам в базата данни си мисля?
 
typeface каза:
Tоест така:
6868.jpg


За рейтовете/цената, а понеже брой хора е винаги еднаква стойност може и да не я вкарвам в базата данни си мисля?
Да, и така до колона 1000 някой ден :D
Записвай данните в масив +
http://php.net/manual/en/function.serialize.php
 
typeface каза:
Tоест така:
6868.jpg


За рейтовете/цената, а понеже брой хора е винаги еднаква стойност може и да не я вкарвам в базата данни си мисля?

Нали вече изяснихме структурата?

typeface каза:
Не съм сигурен, че разбирам. Т.е. предлагаш това?

Код:
user_id     |        number_of_people          |       price
     1                                    1                                    1
     1                                    2                                    10
   ....                                  .......                                ......
     1                                      9                                   100
     2                                      1                                     5
     ...

Или както предложи uphero, да държиш всички стойности в сериализиран масив в едно поле (т.е. да имаш само едно поле, в което да стои "[2,4,6,8,9,11,13....]"). В този случай обаче си по-лимитиран откъм възможности за работа с данните. Например не можеш да сметнеш средно аритметично с една заявка или да видиш най-висока средна стойност или нещо подобно.
 
anonimen каза:
typeface каза:
Tоест така:
6868.jpg


За рейтовете/цената, а понеже брой хора е винаги еднаква стойност може и да не я вкарвам в базата данни си мисля?

Нали вече изяснихме структурата?

typeface каза:
Не съм сигурен, че разбирам. Т.е. предлагаш това?

Код:
user_id     |        number_of_people          |       price
     1                                    1                                    1
     1                                    2                                    10
   ....                                  .......                                ......
     1                                      9                                   100
     2                                      1                                     5
     ...

Или както предложи uphero, да държиш всички стойности в сериализиран масив в едно поле (т.е. да имаш само едно поле, в което да стои "[2,4,6,8,9,11,13....]"). В този случай обаче си по-лимитиран откъм възможности за работа с данните. Например не можеш да сметнеш средно аритметично с една заявка или да видиш най-висока средна стойност или нещо подобно.
А, това не го бях видял, това е другото разумно реение.
Вече според нуждите да си направи избора.
 
typeface каза:
Не съм сигурен, че разбирам. Т.е. предлагаш това?

Код:
user_id     |        number_of_people          |       price
     1                                    1                                    1
     1                                    2                                    10
   ....                                  .......                                ......
     1                                      9                                   100
     2                                      1                                     5
     ...

Ще пробвам днес по този начин и ще пиша/питам допълнително ако нещо не е ясно или има проблем.

Обаче се замислих, че при регистрация на нов юзър, то трябва и да му се запишат нулеви стойности първоначално в тая таблица.

Пример: нов юзър си прави регистрация, автоматично трябва да му създам хора от 1 до 10 с $0 цена в таблицата.
 
typeface каза:
Ще пробвам днес по този начин и ще пиша/питам допълнително ако нещо не е ясно или има проблем.

Обаче се замислих, че при регистрация на нов юзър, то трябва и да му се запишат нулеви стойности първоначално в тая таблица.

Пример: нов юзър си прави регистрация, автоматично трябва да му създам хора от 1 до 10 с $0 цена в таблицата.
Това е поредния проблем при тази структура. Отново помисли дали не искаш да използваш само 1 стойност per user. И както видяхме в темата на @teroristd, неправилен дизайн в началото води до много проблеми в бъдеще.
 
anonimen каза:
Отново помисли дали не искаш да използваш само 1 стойност per user.
Не мога да разбера ^ това. Как така само 1? всеки юзър ще има 10 такива.
 
Това вече го коментирахме, просто ти го посочих, за да видиш как още в началото излизат проблеми, като това с първоначалното създаване на записите:

anonimen каза:
typeface каза:
anonimen каза:
Разбира се аз бих държал само по 1 ст-ст за всеки юзър, като за различен брой хора автоматично ще смятам цената. Защо да държа 10 стойности ако мога да държа 1?
А това как би станало? В смисъл тя цената няма как да се смята, защото е динамична и юзъра си определя. Няма как да знам че Цена 1 + Цена 2 ще даде Цена 3
T.е. ще караш юзера ръчно да си въвежда всяка стойност по отделно? И така за 10 човека? А ако в последствие решиш да са 30? Или 100?

По-скоро въвежда цена за 1 човек и останалото се смята автоматично. Ако иска да има някакво намаление при повече хора, може да добавиш и такава опция, но да държиш по 10 (или 50) повтарящи се записа за всеки юзер е леко казано излишно.

Не вярвам да имаш потребител, за който 1 човек ще струва 5, а 2ма ще струват 4 примерно.
 
Е, не. Това няма как да стане. Това предполага, че трябва да му се зададе примерно ако 1 човек е с цена $5 то втория автоматично да стане на 10, третия на 20/30 и т.н.

Това тотално се различава от идеята всеки да може да си въвежда, каквото си иска.
 

Горе