[mysql] create table on insert

Зачем создавать таблицу для каждой записи?

Не проще ли сделать это через стандартное соотношение один-ко-многим?

В самом примитивном виде будет выглядеть примерно так:

create table properties (
    id int not null auto_increment primary key,
    item_id int,
    name varchar(xxx),
    val varchar(xxx)
)

Эта реализация, естественно, во многом ограничена, - возможны варианты в зависимости от конкретных требований.

Мне не подходит. Нужно для каждой строки таблицы items вести что-то типа истории изменений, т.е. одним свойством тут не ограничишься — нужно что-то расширяемое, например таблица ;)

shylent как раз и подсказал расширяемое.. Почему не создавать новые свойства ваших объектов по требованию?

Раз уж нужна история, добавьте поле date..

Определитесь с набором сущностей. Элементы, Свойства элементов, Изменения свойств элементов. Потом рисуете ER-диаграмму, из которой ясно вытекает стройная и логичная структура из нескольких таблиц, связанных ключами. Динамическое создание таблиц противоречит духу SQL и это костыль!

Почему не подходит? Если нужно хранить версии строк, содержащихся, скажем в таблице 'items', все равно получается такое соотношение: одна строка таблицы 'items' к N 'ревизиям' этой строки, т.е. все также один-ко-многим.

Можно что-то в таком роде попробовать:

create table item (
    id int not null auto_increment primary key,
    f1..
    fN
)

create table item_revision (
    id int not null auto_increment primary key,
    item_id int not null,
    rev int not null,
    f1..
    fN,
    unique ind_rev_item (item_id, rev),
)

Где f1-fN - поля, описывающие сущность 'item'. Rev - номер ревизии.

Можно, в принципе, одной таблицей обойтись, если очень хочется.

Ну вот, теперь мне будут кошмары сниться, про плодящиеся таблицы :(

По теме: http://habrahabr.ru/blogs/sql/101544/

Спасибо за ссылку, почитал. Всё понятно, учту в дальнейшем. Единственное, что могу сказать по поводу предпосылок возникшего у меня вопроса, так это то, что в своём решении я хотел максимально упростить количество и структуру запросов к БД. В предлагаемых же решениях, в силу использования всяких «хитростей» и идеологических моментов типа «духа SQL», обязательно придётся строить сложные (в смысле большие) запросы. Ну где-то так...

DDL запрещено делать в DML.

> что в своём решении я хотел максимально упростить количество и структуру запросов

по таблице на каждую запись? это /0

силу использования всяких «хитростей» и идеологических моментов типа «духа SQL»

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

+1

Лучше научиться строить сложные запросы, чем устраивать хлам из таблиц

Наверное соглашусь, т.к. не силён во внутренностях СУБД.

> не надо ереси. ты пытаешся своё невежество выдать за оптимизацию. тебе подсказали как правильно делать.

Да, именно так. Мой опыт ограничен... Спасибо за подсказки ;)