Форум MySQL

есть объекты и их свойства притом свойства и их количество у каждого объекта разное и каждое имеет своё значение типа :

"окружность" --> радиус (значение) ,диаметр (значение) ,центр(значение).... "треугольник"-- >катет(значение) , гипотенуза(значение) ,углы(значение)... "прямоугольник"-->диагональ(значение) ,сторона (значение)....

Какой должна быть структура таблиц,учитывая, что объекты могут добавляться и естественно со своими свойствами и значениями этих свойств?

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

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

при например такой структуре

CREATE TABLE n_item (   id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,   name TINYTEXT NOT NULL, PRIMARY KEY(id) ) ENGINE=MyISAM; INSERT INTO n_item (name) VALUES ('окружность'), ('треугольник'), ('прямоугольник'); CREATE TABLE n_kind (   id    TINYINT UNSIGNED NOT NULL AUTO_INCREMENT,   i_id SMALLINT UNSIGNED NOT NULL,   name TINYTEXT NOT NULL, PRIMARY KEY(id) ) ENGINE=MyISAM; INSERT INTO n_kind (i_id, name) VALUES (1, 'радиус'), (1, 'диаметр'), (1, 'центр'), (2, 'катет'), (2, 'гипотенуза'), (2, 'углы'), (3, 'диагональ'), (3, 'сторона'); CREATE TABLE params (   id   INT UNSIGNED NOT NULL AUTO_INCREMENT,   i_id SMALLINT UNSIGNED NOT NULL,   k_id TINYINT UNSIGNED NOT NULL,   val TINYTEXT NOT NULL, PRIMARY KEY(id) ) ENGINE=MyISAM; INSERT INTO params (i_id, k_id, val) VALUES (1, 1, '12mm'), (1, 2, '24mm'), (1, 3, '55x22'), (2, 4, 'w'), (2, 5, 'z'), (2, 6, '45x45x90'), (3, 8, 'x'), (3, 7, 'y');

выбрать сразу всё можно будет только наподобии как при GROUP BY
имени параметра, владельцу параметра

SELECT i.*, k.name, p.val   FROM n_item i   LEFT JOIN n_kind k ON k.i_id = i.id   LEFT JOIN params p ON p.k_id=k.id WHERE 1;

или придётся объединять результаты, чтобы не было лишних данных

SELECT i.*, GROUP_CONCAT(CONCAT(k.name, '==', p.val, ' ')) AS val   FROM n_item i   LEFT JOIN n_kind k ON k.i_id = i.id   LEFT JOIN params p ON p.k_id=k.id GROUP BY 1 WHERE 1;

начали за здравие - кончили за упокой.
я имею в виду эти 24mm, 55x22, 45x45x90

так не понятно-же какие там данные ,если углы это углы в градусах минутах и секундах ,
то придётся для треугольника делать 9 полей только на углы., или в datetime впихивать ,)
А вдруг ещё двадцатиугольники надо будет вставить ,) и там стороны на в милиметрах , а в космических расстояниях , как-бы хватило-бы bigtext'a :)

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


Двадцатиугольник, если он правильный и выпуклый, описывается двумя величинами.
А если нет - то это полигон - описывается списком вершин.

// CREATE TABLE n_kind (   id    TINYINT UNSIGNED NOT NULL AUTO_INCREMENT,   i_id SMALLINT UNSIGNED NOT NULL,   name TINYTEXT NOT NULL, PRIMARY KEY(id) ) ENGINE=MyISAM;

при данной структуре разве есть смысл в третьей таблице?
не лучше во вторую добавить поле val?

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

.

а да, точно

(1, 'радиус'),
(1, 'диаметр'),
(1, 'центр'),
(2, 'катет'),
(2, 'гипотенуза'),
(2, 'углы'),
(3, 'диагональ'),
(3, 'сторона');
Вторая таблица должна быть независима от первой

т.е во второй таблице не должно быть i_id
спасибо что заметили

// UPD , тогда те запросы будут выглядеть так

SELECT i.*, k.name, p.val   FROM n_item i   LEFT JOIN params p ON p.i_id=i.id   LEFT JOIN n_kind k ON k.id = p.k_id WHERE 1; SELECT i.*, GROUP_CONCAT(CONCAT(k.name, '==', p.val, ' ')) AS val   FROM n_item i   LEFT JOIN params p ON p.i_id=i.id   LEFT JOIN n_kind k ON k.id = p.k_id GROUP BY 1

А, будьте добры, объясните для чего нужен GROUP_CONCAT(CONCAT(k.name, '==', p.val, ' ')) AS val

кагбы это объЯснить ,)
я не знаю как правильнее будет перевести строчки
This function returns a string result with the concatenated non-NULL
values from a group. It returns NULL if there are no non-NULL values.
, которые во встроенной справке mysql

mysql> HELP GROUP_CONCAT Name: 'GROUP_CONCAT' Description: Syntax: GROUP_CONCAT(expr) This function returns a string result with the concatenated non-NULL values from a group. It returns NULL if there are no non-NULL values. The full syntax is as follows: GROUP_CONCAT([DISTINCT] expr [,expr ...]              [ORDER BY {unsigned_integer | col_name | expr}                  [ASC | DESC] [,col_name ...]]              [SEPARATOR str_val]) URL: http://dev.mysql.com/doc/refman/5.1/en/group-by-functions.html Examples: mysql> SELECT student_name,     ->     GROUP_CONCAT(test_score)     ->     FROM student     ->     GROUP BY student_name; mysql>

спасибо ,понял смысл конструкции.

Функция возвращает в качестве результата строку, представляющую сцепленные существующие значения из группы. Либо NULL , если ни одного (не NULL) значения не нашлось.

А какого типа будет поле "значение" из приведенной вами схемы?

cheops схему-то не привел.
Какое сделаете - такое и будет.
Можете даже все нужные сделать.

Хорошо, сформулирую по другому: какого типа будет поле "значение", если сделать схему согласно вашему описанию?

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

по-моему, поле TEXT не самое удачное.
Тогда уж VARCHAR. Хотя...

сделайте несколько опциональных полей и выбирайте их через COALESCE
http://softtime.ru/forum/read.php?id_forum=3&id_theme=28253

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

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

вот, кстати, нашел один из своих примеров аналогов возможных схем
http://softtime.ru/forum/read.php?id_forum=3&id_theme=58335