Dużo myślałem, próbując wymyślić, jak stworzyć elastyczny system do przechowywania wielu wartości, starając się uniknąć opcji dodawania kolejnych pól do tabeli w przyszłości. Jedyne, o czym mogłem pomyśleć, to zrobić stół, który będzie wyglądał tak:

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    |
+--------+---------+----------+--------+

W ten sposób mógłbym zapisać każdą wartość z rzędu i byłby tak dynamiczny, jak bym chciał. Zdaję sobie sprawę z kiepskiej wydajności przy bardzo długich stołach.

Teraz zorientowałem się również, jak utworzyć widok (front end) wartości w tabeli „Zwykłe”. Wygląda jak normalny stół.

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

Teraz chcę utworzyć tabelę tymczasową zamiast pętli PHP. Jakieś pomysły, jak to zrobić? Jak utworzyć procedurę składowaną, która otrzyma form_id jako parametr i zwróci tabelę taką jak ta?

2
Livne Berebi 7 marzec 2012, 12:13

2 odpowiedzi

Najlepsza odpowiedź

Gratulacje. Na nowo wymyśliłeś model encji-atrybutu.

Ten model istnieje od dłuższego czasu, ale okazał się dosyć źle w systemie relacyjnej bazy danych. Prawdopodobnie nie powinieneś go używać.

Ta odpowiedź to ładna lista plusy i minusy EAV. Największym profesjonalistą jest to, co odkryłeś, łatwiej jest zaprojektować. Największym minusem jest to, o czym tutaj mówię: jest gorszy pod względem wydajności.

Ponieważ zwykle projektujesz znacznie rzadziej niż uruchamiane zapytania, lepiej pomyśleć nieco dłużej podczas projektowania i mieć szybsze zapytania.

1
Community 23 maj 2017, 14:54

NoSQL jest uważany za bardziej dynamiczny Wypróbuj podejście bez schematu. to może być dobry punkt wyjścia:http:// www.igvita.com/2010/03/01/schema-free-mysql-vs-nosql/

0
ApriOri 7 marzec 2012, 16:09