Всем привет. Есть у меня небольшая програмка для личного пользования, вот решил переписать (а то количество быдлокода уже зашкаливает). Заодно и базу переделать, на данный момент в основной таблице нагромоздилось что-то типа такого:


Т.е. не в каждой строке заполнены все поля. Сейчас вместо неприменимых параметров (N/A) стоят Null'ы, но большое количество Null'ов в базе насколько знаю не есть хорошо.

Пока есть две идеи:
- разбить таблицу на несколько равнозначных таблиц разной ширины,
- выделить основную таблицу, в которой заполнены все поля, а параметры, что встречаются не везде - вынести в отдельные таблицы и использовать связь "многие-ко-многим". В данном случае, например, понадобиться три дополнительных таблицы для param3, param4 и param5 соответственно.

Помогите сделать правильный выбор, чтобы в последствии не пожалеть. А может есть другие варианты?

Dimitry SibiryakovНе надо ни выделять, ни разводить толпу дополнительных таблиц. Одна таблица: id, value.
Всё. Связь 1:N.
Не совсем понял... одна таблица всего с двумя колонками? Связь 1:N - это что с чем?

SergueiКак Вам уже сказали 2 таблицы:
1) параметры
2) значение параметра Это я кажется понял как сделать.

Параметры:



Значения парамеров:



Но это не совсе сходиться с Dimitry SibiryakovshckvalСвязь 1:N - это что с чем?
Таблицы значений параметров с таблицей объектов, к которым эти параметры относятся.Ведь нужна ещё третья таблица, таблица собственно объектов?

guest_20040621> А может есть другие варианты?

Куча. Вы главного не сказали: зачем это вам? Что это за параметры, как они меняются, как вы их используете, какая у них размерность, есть ли между ними зависимости? В общем, задачу опишите.

Imho в данном случае "не трогать" - хорошая рекомендация: корректное решение может оказаться достаточно сложным.Зачем мне моя программа? Даже не знаю как сказать, что б жилось легче)) Параметры эти - это результаты парсинга веб-страниц. Зависимости/как меняются: при обновлении какого-параметра с обрабатываемой страницы может меняться другой параметр в пределах одного и того же объекта, в зависимости от стратегии обработки. Параметры могут быть разного типа, например: дата внесения в базу (DATETIME), дата публикации на сайте (DATETIME), окончание срока действия (DATETIME), текст (TEXT), цена (DECIMAL), статус (ENUM), хеш-идентификатор (VARCHAR), ссылка или внешний id (VARCHAR) и т. д. Как использую - выборка/сортировка/поиск. Совсем не трогать не получится, по крайней мере поля-таки иногда приходится добавлять при добавлении нового ресурса. Хотя вряд ли их когда-либо будет 240, думаю и 20 не наберется.

П.С.М.у ТС есть какая-никакая, но работающая программа, с которой он хочет что-то сделать, но пока не понятно для чего и почему у него возникла такая потребность. А раз такая туманная неопределенность, зачем ломать что-то, что уже и так работает?Мне определенно ясно, что код в таком виде каким он есть есть сейчас все трудее читать и дополнять, на него даже смотреть все противнее)). Для рефакторинга и оптимизации есть время и вдохновение, но сначала нужно определиться с базой.

SERG1257Проблема в том что ТС сам не знает что хочет. У него нет четких требований, он хочет "по феншую".Да я действительно не могу предоставить Вам ТЗ, извините. Я не программист и даже не студент, а так себе, энтузиаст. Идеи просто время от времени сами приходят в голову в процессе использования программы или серфинга по интернетам.

Dimitry SibiryakovshckvalВедь нужна ещё третья таблица, таблица собственно объектов?
А у тебя её нет? id твоей "главной таблицы" никуда не ссылается?..
Ссылается на таблицу категорий, но это не то. Вообщем такое у меня получилось: Только ведь параметры, как я писал - они разных типов, если все их перевести в текст при занесении в базу - это ж потом как сортировку делать?

guest_20040621Из вашего описания я понял, что достаточно близкий аналог - лог. Но этого недостаточно: что вы парсите, что делаете с изменениями? Видите ли, как только у вас появляется цена чего-либо, появляется и геморрой. Парсятся элементы страниц - строки таблиц, div'ы и т.п., в зависимости от типа верстки. Результаты предварительно фильтруются по разным критериям, сравниваются с имеющимися в таблице (запрос SELECT), новые добавлятся в таблицу (запрос INSERT) и выводятся на экран. При этом некоторое из уже занесенных в базу результатов тоже могут получить статус новых (запрос UPDATE) и тоже выводятся. После просмотра все помечается как просмотренное (ещё UPDATE) и храниться в базе пока через несколько месяцев не подчистится (запрос DELETE). Если долгое время программой не пользоваться, то потом, чтобы не смотреть все накопившееся сразу, результаты сортируются (SELECT .... ORDER BY ....) и просматриваются частями. Иногда ведется поиск по базе (ещё SELECT). Вроде все, больше операций с базой нет.

SERG1257У EAV, который большинство советует, есть два неисправимых недостаткаВы имеете ввиду эти недостатки?

DirksDRВы поиск "EAV" по форуму делали?Да, я погуглил-почитал немного, спасибо всем за наводку как это называется. Пришел к выводу, что такая модель была бы очень уместна, если программу распространять, чтобы пользователям не приходилось лезть в базу данных при добавлении нового параметра. Но я вроде не планирую. И тут получается дилемма: либо потратить усилия на реализацию и потом постоянно терять в производительности, либо действительно оставить как есть, с кучей нуллов, раз уж оказывается они не так страшны. Если понадобится когда-то добавить параметр, то для меня это несложно. А в код программы при этом все равно лезть, так как единственая причина добавлять ещё новые параметры - это необходимость использовать их при обработке результатов парсинга.

SergueiВы писали? Может просто подумали про это? В вопросе такого не было.Писал в том же сообщении. Извините, наверное действительно нужно было сразу описать подробнее.