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

Форум MySQL

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

 

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

вид форума:
Линейный форум Структурный форум

тема: Много enum и tinyint или 1 varchar?
 
 автор: aetern   (09.08.2013 в 23:53)   письмо автору
 
 

Скажите, что лучше для производительности, скорости обработки и т.п.:
сделать много (15-20) ячеек enum и tinyint с разными данными или одну ячейку varchar, куда записывать через какой-нибудь делитель данные, а потом обрабатывать их в функциями php?
Поиск по данным производиться не будет. Планируется только добавление, чтение и редактирование данных пользователями.
Спасибо.

  Ответить  
 
 автор: Valick   (10.08.2013 в 00:02)   письмо автору
 
   для: aetern   (09.08.2013 в 23:53)
 

трудно ответить, надо больше конкретной информации, ну и скорее всего надо будет тестировать оба варианта.

  Ответить  
 
 автор: Sfinks   (10.08.2013 в 00:49)   письмо автору
 
   для: aetern   (09.08.2013 в 23:53)
 

Если вы ТОЧНО(!!!) знаете, что поиск по этим данным (и выборка основанная на этих данных) производиться никогда не будет, то можно даже VARCHAR (или TEXT) и сериализованный массив PHP в нем.

С другой стороны, если у вас 15-20 полей с ограниченным набором значений, а строк планируется эдак миллион, то вы не плохо сэкономите место (а следовательно поднимите скорость работы с таблицей), если будуте использовать enum. Хотя это будет и погеморройнее.

Потом, если вы будете эту таблицу JOIN'ить с чем либо, то при использовании text(varchar) результат JOUN'а с очень высокой вероятностью будет постоянно сбрасываться на диск в temp... Что очень медленно.

В основном, как-то так. Смотрите сами.... Зависит от предполагаемого объема и нагрузки.

  Ответить  
 
 автор: cheops   (11.08.2013 в 16:57)   письмо автору
 
   для: aetern   (09.08.2013 в 23:53)
 

Много ячеек будет работать быстрее (в том числе на вставку), если у вас в таблице не будет других VARCHAR и столбцов, допускающих NULL. У вас будет фиксированный размер записи - их обработка всегда идет быстрее, чем переменных (которые еще к тому же хранятся отдельно от других столбцов).

  Ответить  
 
 автор: aetern   (18.08.2013 в 15:49)   письмо автору
 
   для: cheops   (11.08.2013 в 16:57)
 

Спасибо.
А что страшного в NULL?

И еще вопрос.
Какой из вариантов эффективнее и правильнее:

  `s1` enum('1','2') DEFAULT NULL,
  `s2` enum('0','1','2') NOT NULL DEFAULT '0',
  `s3` enum('1','2') NOT NULL


Если данные идут из формы:
<select name="question">
<option value="" selected="selected"></option>
<option value="1">Да</option>
<option value="2">Нет</option>
</select>


и как в каждом случае делать проверку на отсутствие записи в ячейке?
Правильны ли эти варианты?
if ($s1!="NULL")
if ($s2!="0")
if ($s3!="")

  Ответить  
 
 автор: cheops   (19.08.2013 в 07:53)   письмо автору
 
   для: aetern   (18.08.2013 в 15:49)
 

1. Ничего страшного нет, просто эти значения хранятся в той же области памяти, где и varchar. Поэтому если у вас все остальные столбцы фиксированные, то с NULL фиксированной записи все равно не получатся.

2. В форме у вас нет строк "NULL" или "0", поэтому правилен третий вариант, при условии, конечно, что $s3 содержит значение, переданное из формы.

  Ответить  
Rambler's Top100
вверх

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