Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Разное

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум (новые сообщения вниз) Структурный форум

тема: пользовательские опросы в liteforum

Сообщения:  [1-10]    [11-20]   [21-30]  [31-35] 

 
 автор: Trianon   (28.02.2011 в 00:10)   письмо автору
10.3 Кб
 
   для: Trianon   (28.02.2011 в 00:09)
 

скриншот

  Ответить  
 
 автор: Trianon   (28.02.2011 в 00:09)   письмо автору
32.6 Кб
 
   для: Trianon   (21.02.2011 в 21:14)
 

версия с рейтинговыми и оценочными опросами.

  Ответить  
 
 автор: cheops   (23.02.2011 в 00:30)   письмо автору
 
   для: Trianon   (23.02.2011 в 00:29)
 

А ну в этом смысле конечно.

  Ответить  
 
 автор: Trianon   (23.02.2011 в 00:29)   письмо автору
 
   для: cheops   (23.02.2011 в 00:27)
 

я к тому, что в хранении enum нет ничего поразрядного. Обычное число лежит.

  Ответить  
 
 автор: cheops   (23.02.2011 в 00:27)   письмо автору
 
   для: Trianon   (23.02.2011 в 00:20)
 

Думаю 32-х позиций более чем достаточно

>SET - да. ENUM - врядли.
>An enumeration can have a maximum of 65,535 elements.
Да нет, похоже все-таки INT (причем 16-битная положительная часть), а строковые имена в заголовке таблицы хранятся.

  Ответить  
 
 автор: Trianon   (23.02.2011 в 00:20)   письмо автору
 
   для: cheops   (22.02.2011 в 23:54)
 

SET - да. ENUM - врядли.

Типа, соответствующего BIGINT, в php нет. Значит - преобразования и потери времени.
Потенциальная длина таблицы тоже вынуждала экономить.
Полагаете, стоит сделать BIGINT?

  Ответить  
 
 автор: cheops   (22.02.2011 в 23:54)   письмо автору
 
   для: Лена   (22.02.2011 в 23:10)
 

Можно в 64, кстати, MySQL в типах ENUM и SET то же самое делает, берет целый тип и хранит отдельные значения в отдельных битах.

  Ответить  
 
 автор: Trianon   (22.02.2011 в 23:32)   письмо автору
 
   для: Лена   (22.02.2011 в 23:10)
 

а во сколько надо?

  Ответить  
 
 автор: Лена   (22.02.2011 в 23:10)   письмо автору
 
   для: Trianon   (22.02.2011 в 14:11)
 

А почему надо засовывать в 32 бита?

  Ответить  
 
 автор: Trianon   (22.02.2011 в 14:11)   письмо автору
 
   для: Лена   (22.02.2011 в 13:54)
 

>Ну тогда как бы нужно выбирать из двух зол лучшее: или текстовое поле, или выпадающий список.

Была даже идея реализовать оба варианта.

>При текстовом возникает проблема проверить, чтобы вводили то, что нужно, при выпадающем списке - проблема: список будет километровым, если диапазон выбора большой, например, если предложат что-то оценить по 100% шкале - все сто цифр, получается, будут в списке.

Тут еще одно но. болььших цифр всяко не будет - их просто негде хранить.
Пока что в предполагается ограничиться 8-9 вариантами и 10-бальной системой оценок.
Большее в 32 бита не засунуть.

>Все ж происходит на клиенте, и пока пользователь не нажмет кнопку(заполнит поле), мы о его "рейтинговых предпочтениях" не узнаем. Выбор здесь ограничен - типов полей у формы не так много.

конечно

  Ответить  

Сообщения:  [1-10]    [11-20]   [21-30]  [31-35] 

Форум разработан IT-студией SoftTime
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования