Решение с динамическим контентом для гибкой таблицы MySQL - PullRequest
1 голос
/ 07 марта 2012

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

CREATE TABLE IF NOT EXISTS `form_data` (
    `id` int(11) NOT NULL auto_increment,
    `name` varchar(50) NOT NULL,
    `value` varchar(500) default NULL,
    `form_id` int(11) NOT NULL,
    PRIMARY KEY  (`id`)
)

+--------+---------+----------+--------+
|   id   |  name   |  value   | form_id|
+--------+---------+----------+--------+
|  100   |fullname |  Steve   |   1    |
+--------+---------+----------+--------+
|  101   |email    |ab@c.com  |   1    |
+--------+---------+----------+--------+
|  102   |fullname |  John    |   1    |
+--------+---------+----------+--------+
|  103   |email    |cd@c.com  |   1    |
+--------+---------+----------+--------+

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

Теперь я также выяснил, как сделать представление (передний конец) значений в «обычной» таблице.Выглядит как обычная таблица.

+--------+---------+----------+
|  ID    | Email   |Fullname  |
+--------+---------+----------+
|   1    |ab@c.com | Steve    |
+--------+---------+----------+
|   2    |cd@c.com | John     |
+--------+---------+----------+

Теперь я хочу создать временную таблицу вместо циклов PHP.Есть идеи, как сделать эту работу?Как создать хранимую процедуру, которая получит form_id в качестве параметра и вернет таблицу, подобную этой?

Ответы [ 2 ]

0 голосов
/ 07 марта 2012

NoSQL считается более динамичным. Попробуйте бессхемный подход.это может быть отправной точкой goot: http://www.igvita.com/2010/03/01/schema-free-mysql-vs-nosql/

0 голосов
/ 07 марта 2012

Поздравления. Вы заново изобрели модель Entity-Attribute-Value .

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

Этот ответ дает хороший список плюсов и минусов EAV. Самый большой профессионал - это то, что вы обнаружили, его легче спроектировать. Самый большой минус - то, что я здесь говорю: это хуже по производительности.

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

...