Есть товар с характеристиками
характеристика_1
характеристика_2
характеристика_3

характеристика_3 это большой текст на страниц 200
он может быть, может не быть.

Выводится он тоже не всегда. По специальному запросу. Но у одного товара только одно описание.

Добавлено через 10 минут и 7 секунд
Я нашел 2 варианта хранения данных.
Все вбить в одну таблицу.

Разбить на 2 таблици.
Первая это
товар с характеристиками
характеристика_1
характеристика_2


вторая это
id товара и
характеристика_3

Но при выводе информации про товара я должен знать присутствует ли у него характеристика_3 (для того что бы знать давать на нее ссылку или нет) потому в таблицу товара добавляю еще одно поле типа enum('yes', 'no').
Вопрос вот в чем. Как лучше сделать
В одной таблице или в двух?

Это сообщение отредактировал(а) taral - 23.12.2008, 18:01

имхо, текст (коли это описалово) лучше в файле, а в поле линк на него и инклудить при наличии оного

в плане нормализации БД лучше избегать полей в которых может часто отсутствовать значение. Поэтому такая схема вполне приемлема.
Можно вытаскивать все одни запросом через left join, тогда поле enum лишнее.
далее как писал bars80080.

Ну я специально написал что нужно знать есть ли описание у товара.
Просто допустим я вывожу 15 товаров с базы.  И мне нужно знать есть ли описание у товара (для того чтобы знать выводить на него ссылку или нет) Если не будет поля енум то для того что бы узнать мне придется делать запрос на таблицу с описаниями.
Вопрос я задал вот почему.
Меня интересовало если я делаю выборку по базе только определенных столбцов замедлится ли работа базы если будут присутствовать поля с большими текстами.
И замедлят ли они поиск по базе.

В принципе решение с записью в файлы текстов неплохое. Обдумаю его. спасибо за идею.

зачем делать еще запрос если ты объединением (join) уже подключаешь вторую таблицу?? У тебя уже характеристика_3 присутствует в результирующем наборе, тебе только остается проверить пусто поле или нет и если нет вывести.
Если  писать содержимое характеристика_3 в файл, а в базе хранить только ссылку на него, то это даст выигрыш в производительности.

Вы меня не правильно поняли, или я не ясно выразил свою мысль.
Моя идея вот в чем.
Вывожу 15 товаров. (таблицу с описанием я вообще не трогаю)
Использую только таблицу_1. Если значение енум - yes я помимо характеристик товара вывожу ссылку на описание. Она формируется на основе id товара.
Если пользователь переходит по ссылке то тут задействуеться таблица_2 (а первую вообще не трогаем). И вывожу описание товара.
Сразу скажу что пример чисто схематический. Поскольку вряд ли кому то нужно видеть чисто описание товара без его характеристик.
Просто в своей работе я использую аякс. И хочу сделать погрузку описания по требованию пользователя. В другом случае ее вообще не трогать. Что бы избежать лишней нагрузки на базу.
Потому и вопрос задал. Я хотел узнать если в базе будет "большое боле" и оно не всегда будет использоваться то есть смысл вынести его отдельно в таблицу (под смыслом я имел в виду нагрузка уменьшится или нет.) Надеюсь теперь ясно зачем нужен енум.
А join я вообще откинул. Если использовать его не проще тогда в одной таблице все и хранить.
А вообще я все больше склоняюсь к вынесению текста в txt файлы. Так отпадет нужда в енуме и второй таблице.

Это сообщение отредактировал(а) taral - 23.12.2008, 23:27

если я понял правильно, то не вижу особого смысла иметь 2 таблицы. Если есть поле "Характеристика_3" которое может быть иногда пустым, то почему оно должно занимать лишнее место? Есть данные - добавь, нет - ну значит нет. Единственное, это наверное нужно применять оптимизацию таблицы при редактировании или удалении информации из этого поля.. НУ я так понимаю тип этого поля TEXT

Что касается использования файлов... А зачем? таблицы надёжнее, да и работать с ними приятнее 

Gold Dragon, 
и фотографии весом в несколько мегов и файлы прикрепленные для скачивания тоже будешь в mysql засовывать?
есть удобство с одной стороны, а есть не менне маловажная вещь производительность с другой...

ну вообще-то, разговор шёл только про текст, так что не нужно перегибать палку 

а вот что касается производительности, то я как-то не уверен что с файлами это будет производительнее...

как они могут быть не производительней, если БД - те же файлы и есть, только обременённые дополнительными операциями 

протягивать каждый раз дикие объёмы текста через mysql-сервер... 

ну к примеру, практически все движки (CMS) хранят весь контент в базе. Не думаю что разработчики этого не знали  . Я понимаю что база это те же файлы, только принцип обработки их другой.. 
А вот плюсов больше, например, обширная система запросов, т.е. что хочешь то и творишь, или что очень важное, система резервирования и т.п.

Хотя я абсолютно не возражаю чтобы в поле таблицы хранить только ссылку на текстовый файл 

знавал я пару разработчиков...

на самом деле, они используют БД от лени. фишка в чём, если есть файл - то его надо подключать, в таком случае, без дополнительной системы проверок этот файл (если его может редактировать юзер) становится потенциальной угрозой, ведь туда можно зафигарить любой код. чтобы не париться, они поступают в итоге с многокилобайтными данными также как с простым поле "фамилия" к примеру, естесственно обосновывая это какими-нибудь причинами удобства и всё-такое, хотя достаточно было, при желании, построить доп.обработчики и интерфей для его настройки

те же самые разработчики славятся тем, что открытые CMS почти всегда очень тяжёлые и медленно работающие, в то время как коммерческие специально затачиваются под клиента, и там они борются за каждую секунду (если хорошая контора)



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

Imho, надо просто определить, что-же такое файл 

Файл, с точки зрения CMS-ки - это длинная, неделимая последовательность байт, в которой не надо искать, которую не надо редактировать.

Если доопределить понятия "длинная", "не надо искать" и "не надо редактировать", легко получается однозначный критерий, чего и где хранить    

Ну да... а человек, с точки зрения Аристотеля - "двуногое, без перьев"...   

bars80080, прав на все сто 
Подменить файл всё таки проще чем запись в базе.... хотя тоже спорно... 
А что касается открытых и коммерческих - согласен абсолютно... CMS для частных заказов точно не катит... Но принципы безопасности и построения системы аналогичная.. Разрабатывая системы я лично столкнулся с проблемой что файлы (рабочие файлы, а не файлы базы  ) очень капризны порой к требованию серверов. Да и если писать в файл то он должен быть 777, а это очень опасно. Если сервер частный то вопросов нет.. а вот если хостинг купленный, то нужно иметь очень хорошие отношения чтобы хостер позволил включить или отключить какую-нибудь функцию... и это очень часто бывает 

А вот храня текст в базе, проблем никогда не испытывал  

два последних проекта и именно это нужно  много запросов, много поиска и много сортировки... 

Хотя конечно всё зависит от проекта.. Но я больше не использую файлы, только базу ...  это моё конечно мнение, но мне так удобнее и проще 


ps
пара гадостей:
- если нужно украсть сайт, достаточно сделать дамп
- если заказчик кинет, достаточно лишить его базы 

pss
не следуйте этим гадостям, это только для очень плохих людей ;) А вообще, С Новым Годом всех!!!


Это сообщение отредактировал(а) Gold Dragon - 31.12.2008, 13:47

хм... Ну честно говоря, "описание на страниц 200", вообще лучше в окошко браузера не выводить а хранить спокойно в вордовском доке (например) и предлагать пользователю скачать, если он того хочет. Храните в базе описание скажем на страницу-две, заинтересуйте пользователя этим. А с файлами связываться... Ну не знаю, если у вас вместо интерфейса редактирование устраивает редактирование через FTP и акелпад, то почему бы и нет...

Насчет оптимизации базы... Ну, друзья, мы уже слава богу в 2009 году живем, сегодня уже производственные мощности позволяют MATCH AGAINST на таблицы размером в гигабайт выполнять менее чем за секунду... хотя нет, наверное приврал малость, но тем не менее. По-моему, вопрос того что скрипт будет выполняться не 0.1 сек а 0.11 сек, не стоит ставить во внимание, если учесть, что оптимизация займет хотя бы час.

Ну и напоследок не дай вам бог делать поиск по файлам))