[django] создание таблиц «на лету»

А вам не кажется, что вы просто неправильно спроектировали БД под каталог продукции, даже с учетом разных типов товаров можно спроектировать базу данных таким образом, чтобы товары сортировались по свойствам и категориям и вовсе не обязательно при этом менять постоянно структуру таблицы добавляя новые столбцы

>Т.е. нельзя создать универсальную форму для добавления всех товаров. Суть вот в чем. Может кто знает, умеет ли жданга создавать таблицы в бд «на лету»?

Так не делают. Гугли EAV.

Для вас, быдлокодеров, document-oriented databases придумали.

У меня нет всех свойств, они будут добавляться новые.

>Для вас, быдлокодеров, document-oriented databases придумали.

Вот только времени столько нет, уважаемый анонимный гуру. Проще все на php написать.

>Так не делают. Гугли EAV.

Гуглил и говорил на эту тему. Народ сходится во мнении, что это корявая поделка и глючит при больших объемах.

общие данные храни в обычных полях, а для остального отведи текстовое поле в котором храни данные в виде json.

>общие данные храни в обычных полях, а для остального отведи текстовое поле в котором храни данные в виде json.

И забудь про поиск, да.

Ну тогда другой вариант:

Свойство: id, name

ТоварСвойство: product_id, property_id, value

>Гуглил и говорил на эту тему. Народ сходится во мнении, что это корявая поделка и глючит при больших объемах.

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

В случае, когда количество свойств действительно неограничено, на РСУБД ничего кроме EAV не сделать. Из альтернатив - всякие разные sparse table (можно сделать по-разному, но всё равно упрёшься в количество колонок), либо XML/JSON поля, но по ним нет приличного поиска.

Изменение таблиц на лету - плохо. На крупной таблице с кучей записей ALTER TABLE может отрабатывать даже десятки минут, в течение которых сайт будет недоступен.

Так что для РСУБД - только EAV (и это печально). Либо взять документ-ориентированную БД, её как раз для этого придумали.

>Ну тогда другой вариант:

Вот это и есть EAV, чтоб его.

Только лучше Свойство делать либо в виде property_int, property_char, property_date, либо делать несколько таблиц для разных типов, и на ходу соображать, какой тип данных нужен.

Потому что если в системе без распределения типов надо будет, например, сделать запрос по дате, то придётся сначала доставать все данные и преобразовывать строки в timestamp-ы, а потом уже сравнивать. То есть производительность просто убьётся в ноль. То же самое и для числовых полей.

> ....сделать запрос по дате, то придётся сначала доставать все данные и преобразовывать

Например в postgresql есть индексы по функциям... Но да, либо EAV либо монгодб.

>Например в postgresql есть индексы по функциям...

А всё равно медленно выйдет. Если есть, например, десяток тысяч нужных строк, то БД всё равно будет делать преобразования. Быстрее, чем на стороне питона, но всё равно не то.

Кстати, если уж так, то в postgresql есть тип array, причем возможно делать динамические массивы. Разработчики говорили, что с производительностью всё ок. Но реализация этого всего в коде будет нетривиальна, т.к. надо будет хранить кучу метаинформации, да и джанговские модели не умеют массивы.

>>Только лучше Свойство делать либо в виде property_int, property_char, property_date, либо делать несколько таблиц для разных типов, и на ходу соображать, какой тип данных нужен.

Вот я так и думаю делать.

> А всё равно медленно выйдет. Если есть, например, десяток тысяч нужных строк, то БД всё равно будет делать преобразования.

ШТО? Какие преобразования? http://www.postgresql.org/docs/8.4/interactive/indexes-expressional.html читать до просветления

>ШТО? Какие преобразования? http://www.postgresql.org/docs/8.4/interactive/indexes-expressional.html читать до просветления

Прочитал. Понял. Больше глупости говорить не буду.

Спасибо. Не знал, а он ещё и такое может. Кажется я выбрал правильную СУБД.

Вот только времени столько нет

тебе прще всё с нуля переписать, нежели поставить БД, по которой есть тонна макулатуры? это круто

>тебе прще всё с нуля переписать, нежели поставить БД, по которой есть тонна макулатуры? это круто

я про nosql. Проще на php все вообще с нуля переписать.

>тебе прще всё с нуля переписать, нежели поставить БД, по которой есть тонна макулатуры? это круто

я про nosql. Проще на php все вообще с нуля переписать.

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

LDAP + ldapalchemy. Динамичность свойств, скорость, in-server consistency checking

>Продукция разнообразная. Т.е. нельзя создать универсальную форму для добавления всех товаров

1. Можно при нормальном проектировании.

2. Если нормально спроектировать не получатся, есть же документо-ориентированные NoSQL: MongoDB и т.п.