Проектирование базы данных

kirilev, да. это выход. но запросы тут получяться бешеные.

Цитата ("WebDesignStudio"):

kirilev, да. это выход. но запросы тут получяться бешеные.

да не, конечно, надо хранить все в разных таблицах - т.е. "группы свойств", "свойства", "товары". Нифига и не бешенные запросы, кстати) подумаешь, один запрос с объединением 3 табличек, причем с очень малым кол-вом информации) + кэширование спасет в любом случае

Цитата ("Paralysed"):

один запрос с объединением 3 табличек, причем с очень малым кол-вом информации

ну очень может и не очень... если товаров 100к и полей по 10, то уже миллиончик.

Цитата ("WebDesignStudio"):

kirilev, да. это выход.

тоже самое о чем и я говорю. Только единицы измерения хорошо бы отделять.

WebDesignStudio если есть возможность написать запросы сложнее select * FROM `table` - проблем с выборкой быть не должно, inner join, inner left должно хватить, или можно попросить кого-то написать апи для выборки данных с БД.

kirilev, со сложными запросами я разберусь. Только вот как серверу от этого будет?

Цитата ("frig"):

если товаров 100к и полей по 10, то уже миллиончик.

Для этого есть LIMIT, врятли нужно столько записей на одной странице выводить )

Цитата ("frig"):

тоже самое о чем и я говорю. Только единицы измерения хорошо бы отделять.

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

Уже голова начинает болеть
Там еще шаблоны форм добавления хранить. Примерно так же.

Цитата ("WebDesignStudio"):

Только вот как серверу от этого будет?

От запросов всё и зависит .. Если там накрутить без надобности чего-то страшного - будет нагружать немного.. mysql он же быстрый, справится, лично я лучшего решения пока не вижу.. в самого были подобные задачи, именно так и делал..
- проигрыш - время разработки увеличивается, так как путь более сложный, чем например всё в одну таблицу и чёта там с ним делать, да и управление данными - нужно мозг чуть поднапрячь;
- выигрыш - в ходе работы всё как по маслу.

Цитата ("frig"):

ну очень может и не очень... если товаров 100к и полей по 10, то уже миллиончик.

Эт зачем столько товаров выводить с объединением таблиц? В общем каталоге вряд ли они будут со свойствами выводится - простой запрос, а вот при просмотре отдельного товара будут объединяться в результирующую таблицу всего несколько строк из каждой таблицы - т.е. имеем один товар, одна группа свойств и десяток самих свойств) маленькая табличка в результате, никаких 100к )

Не думаете ж вы, что мускул сначала объединяет агромные таблицы со всеми возможными вариантами объединения всех строк, а потом выполняет where для сортировки результата ) это была бы мегажесть

Цитата ("WebDesignStudio"):

Там еще шаблоны форм добавления хранить. Примерно так же.

почему примерно так-же?.. просто добавить в каждую группу properies_groups свойство template
И каждый итем будет иметь свой шаблон..

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

templates
|id|propertiesgroup_id|template|
1 - 1 - "шаблон первой группы фототехники, Код шаблона, имя шаблона, или ссылка на файл шаблона"
1 - 2 - "шаблон группы автомобилейКод шаблона, имя шаблона, или ссылка на файл шаблона"

Цитата ("Paralysed"):

Эт зачем столько товаров выводить с объединением таблиц?

при поиске по одному из параметров, например, придется этим миллионом ворочать. Искать то надо будет в таблице такого размера от LIMIT она меньше не станет . Да и сам limit там будет не без особенностей. Вполне реальная задача. Я не говорю что она не выполнимая, я оспариваю Цитата ("Paralysed"):

с очень малым кол-вом информации

в остальных случая там вообще будет кэш использоваться. Денормализация все решит. А вот при поиске придется перелопачивать все.

Кодда читайте - «A Relational Model of Data for Large Shared Data Banks»

Цитата ("frig"):

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

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

можно даже по другому сделать - при сохранении товара вбивать в текстовом виде все параметры в одно поле, и искать полнотекстовым поиском, оч быстро)

П.С. Я про limit ничо не говорил)

Лимит если речь о выводе, того же поиска..

А это не нам миллионами ворочать, это задача mysql.. главное чтобы нормализация была.. и запросы совестные.. да и если поиск по одному параметру - написал запрос небольшой - и нашел и вывел нужное количество записей, как результат поиска (с нормально сделанным постраничным поиском задача проще простого)

да, работает эта субд с огромными массивами данных, потому нечего здесь боятся каких-то 100к записей... правда бывает что ОЗУ для выполнения рнр-скрипта не хватает (если попробовать 100к записей со всеми свойствами выгрузить в один массив) - но это проблема в программисте, а не в рнр или в mysql...

как-то так

Цитата ("Paralysed"):

Нюю.. каким ж миллионом, у нас же все свойства и параметры хранятся в отдельной таблице

И из нее надо будет выбирать. Не?

Цитата ("kirilev"):

потому нечего здесь боятся каких-то 100к записей...

100к товаров у каждого по 10 характеристик - сколько выйдет?

Миллион это не много, я ж ничего против не имею. Но это и не элементарно и внимательным тоже надо быть.

Цитата ("frig"):

И из нее надо будет выбирать. Не?

ой, это все фигня, чесслово. Мускул для этого и создавался. Подумаешь, выборка из миллиона записей, большая проблема.. У меня блоги работали когда-то на хостинге мажордомо за 250 рублей кажись.. очень тормозной был, поганка, сейчас-то они немного раскочегарились в лучшую сторону. Посещаемость была 800-900 в день, база постов к 300к подходила, ну и как в этом случае тоже - еще умножаем, как вы говорите, на 10-100 комментариев и вперед. Работал! Немного (реально немного) тормозил, но работал отлично)

чо уж говорить о каких-то 100к, если особенно сервак свой и т.д.) вообще тьфу

Цитата ("frig"):

100к товаров у каждого по 10 характеристик - сколько выйдет?

Нам не интересно сколько выйдет, у нас же нету задачи подсчитать количество записей ).. если взять во внимание типы полей и подсчитать сколько байт получится - можно быть в шоке ).. но зачем это нужно?

Цитата ("Paralysed"):

Мускул для этого и создавался.

Вот вот.. к этому и веду )

УПД: да что там 100к товаров.. вот у кого-то БД в терабайт, и выбирает же как-то, и ищет тоже то что нужно.. не будем сеять паникУ ))

УПД: вот мне самом интересно поэкспериментировать и опытным путём прийти к выводу как лучше запросы писать и как их можно оптимизировать (для поиска\выборки данных можно придумать как минимум два sql-решения).. выделить около 600-700Гб локального пространства, и извращатся там.. найти бы времени свободного - и всё.. гуляй душа )))

Цитата ("Paralysed"):

Подумаешь, выборка из миллиона записей, большая проблема..

я еще раз обращаю внимание на то, что это не большая проблема, не нереальная задача а только не

Цитата ("Paralysed"):

причем с очень малым кол-вом информации

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

Я бы сделал:

Одна таблица для хранения информации о товаре. Типа
id | catId | titile | type

А дальше для каждого type отдельная таблица со специализированными полями.

Anexroid, и что, создавать таблицы в процессе работы?