Вводные данные:
- есть некие сущности, у всех есть названия и свой набор характеристик
- характеристики могут быть любыми
Задача:
нужно спроектировать БД для хранения этих данных
Моё решение:
таблица entities, в которой хранятся сущности и их имена:
id | name
таблица properties, в ней хранятся названия характеристик:
id | name
таблица values со значениями характеристик для каждой сущности:
entity_id | property_id | value
Всё вроде бы хорошо, но есть (не)большая проблема. Значение характеристики может быть естественно любого типа, от tinyint(1) и enum до text, исходя из этого мне видится только одно грязное решение для вышепредложенного варианта - поле value сделать text.
У кого есть другие варианты?
Спустя 13 минут, 55 секунд (15.03.2012 - 19:10) vital написал(а):
| Цитата |
| одно грязное решение для |
А что мешает еще сделать табличку values, в которой хранить property_id/enity_id
три колонки с возможностью быть null и типами varchar/text/int/etc, и колонку value_type = 1/2/3/4 соответственно.
И при создании характеристики просить пользователя указать тип характеристики - текст, число, выбор галочками етк.
Ну не совсем так, но идея должна быть ясна.
Спустя 33 минуты, 9 секунд (15.03.2012 - 19:43) johniek_comp написал(а):
а что такого плохого в text?
Спустя 40 минут, 11 секунд (15.03.2012 - 20:24) Invis1ble написал(а):
vital
т.е. ты имеешь ввиду сделать вместо одного поля `values`.`value` несколько полей - `values`.`int` INT NULL DEFAULT NULL, `values`.`text` TEXT NULL DEFAULT NULL и т.п.? Как быть с enum и set?
т.е. ты имеешь ввиду сделать вместо одного поля `values`.`value` несколько полей - `values`.`int` INT NULL DEFAULT NULL, `values`.`text` TEXT NULL DEFAULT NULL и т.п.? Как быть с enum и set?
Спустя 6 минут, 59 секунд (15.03.2012 - 20:31) inpost написал(а):
Invis1ble
А зачем?
А зачем?
Спустя 2 минуты, 14 секунд (15.03.2012 - 20:33) Invis1ble написал(а):
что зачем?
Спустя 18 минут, 34 секунды (15.03.2012 - 20:51) inpost написал(а):
Если описание может быть разным, как числовым так и текстовым, то почему не хочешь просто text? Зачем что-то изобретать? Мне этот момент непонятен.
Спустя 59 минут, 32 секунды (15.03.2012 - 21:51) Invis1ble написал(а):
Не нравится, потому что оверхед + необходимость кастовать типы при надобности, да и вообще не тру это...
Изобретать я ничего не хочу, поэтому создал топик, чтобы опытные люди поделились своими мыслями
Спустя 19 минут, 11 секунд Invis1ble написал(а):
Наверное сделаю все-таки value типом text и доп. поле type в таблице properties
Если у кого-то есть еще идеи - пишите )
Изобретать я ничего не хочу, поэтому создал топик, чтобы опытные люди поделились своими мыслями
Спустя 19 минут, 11 секунд Invis1ble написал(а):
Наверное сделаю все-таки value типом text и доп. поле type в таблице properties
Если у кого-то есть еще идеи - пишите )
Спустя 1 час, 22 минуты, 19 секунд (15.03.2012 - 23:13) inpost написал(а):
Invis1ble
Мне кажется, что под конкретные задачи стоит писать конкретную БД.
Сущностями могут быть фильмы, а их свойства - жанры. Вуаля, 3 таблицы:
фильмы, жанры, id_связь.
Сущностями может быть машина. А её свойствами: множество параметров: 2 таблицы:
машина, таблица свойств, если конкретные данные не ввели, то колонка пустая, где каждое конкретное свойство - ячейка.
А если у сущности (з/п) есть лишь 1 свойство - сумма, то 1 таблица, где лишь 1 поле, сколько выплачивать з/п конкретному человеку. При этом сама сущность вообще не будет в БД представляться.
3 разных варианта на 3 разных ситуации, не зря же называют таких людей: "проектировщики Баз Данных", а не просто "копи-пастеры".
Как ты любишь говорить, нужна конкретика.
И к тому же, если ты не предусматриваешь идеи поиска внутри свойства, или сортировки в виде чисел, то ставь текстовое поле.
Мне кажется, что под конкретные задачи стоит писать конкретную БД.
Сущностями могут быть фильмы, а их свойства - жанры. Вуаля, 3 таблицы:
фильмы, жанры, id_связь.
Сущностями может быть машина. А её свойствами: множество параметров: 2 таблицы:
машина, таблица свойств, если конкретные данные не ввели, то колонка пустая, где каждое конкретное свойство - ячейка.
А если у сущности (з/п) есть лишь 1 свойство - сумма, то 1 таблица, где лишь 1 поле, сколько выплачивать з/п конкретному человеку. При этом сама сущность вообще не будет в БД представляться.
3 разных варианта на 3 разных ситуации, не зря же называют таких людей: "проектировщики Баз Данных", а не просто "копи-пастеры".
Как ты любишь говорить, нужна конкретика.
И к тому же, если ты не предусматриваешь идеи поиска внутри свойства, или сортировки в виде чисел, то ставь текстовое поле.
Спустя 26 минут, 21 секунда (15.03.2012 - 23:40) Invis1ble написал(а):
| Цитата |
| Как ты любишь говорить, нужна конкретика. |
в данном случае не нужна, я намеренно опустил детали, ибо они не имеют отношения к задаче
могу провести аналогию, чтоб было понятней
1-я сущность - Вася; свойства: возраст - 25 лет, кол-во рук - 2, кол-во ног - 2, цвет кожи - белый и т.д.
2-я сущность - Земля; свойства: возраст - 4.5 млрд лет, население - 7 млрд и т.д.
n-я сущность - %название%; свойства: %свойство1% - %значение1% и т.д.
Спустя 9 минут, 45 секунд (15.03.2012 - 23:49) Invis1ble написал(а):
Под данную задачу наверное больше MongoDB подходит, но в проекте используется MySQL
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль