Комментарии 98
Спрячь под хабракат.
0
Спасибо, это было интересно.
+1 топику, +1 в карму
Теперь можно переносить в коллективный блог. : )
Если есть какой тематический, сообщи плиз.
Интересно читать такие вещи.
+1 топику, +1 в карму
Теперь можно переносить в коллективный блог. : )
Если есть какой тематический, сообщи плиз.
Интересно читать такие вещи.
+1
Наверное SQL? Наверное стоит перед переносом подредактировать статью, литературный стиль, орфографию. Писалось "по быстренькому", поэтому не уверен что все всем понятно. Давайте сначала обсудим, а там посмотрим.
0
Мей би. Хотя тут мне более интересен не "чистый" SQL, а именно практические примеры реализации БД под конкретные нужды.
0
Я не разработчик и не программист, "просто примусы починяю". : )
Сейчас думаю над небольшой БД для домашней бухгалтерии.
И прежде чем изобретать велосипед, хотелось бы ознакомиться, может кто до меня уже это делал.
Сейчас думаю над небольшой БД для домашней бухгалтерии.
И прежде чем изобретать велосипед, хотелось бы ознакомиться, может кто до меня уже это делал.
0
Сейчас думаю над небольшой БД для домашней бухгалтерии.
может кто до меня уже это делал
Это уж точно ))) Лучше всего готовую скачать. Есть неплохие варианты рублей за 300-500. Это всяко дешевле, чем Ваше время, потраченное на проектирование, на реализацию, а потом на перепроектирование и перереализацию задуманного. imho, конечно.
0
Я конечно до мелочей докапываюсь, но лучше исправьте childs на children, так правильней.
0
Если будете редактировать, неплохо бы заменить "childs" на "children" :)
0
я за раскрытие темы. и за перемещение статьи в sql.
0
НЛО прилетело и опубликовало эту надпись здесь
По поводу типа связей, этот вопрос так же решен, но другим способом. Не хочется углубляться сейчас в подробности.
Насчет второго замечания, не согласен. Связи ограничивать не так уж необходимо. Но если так уж хочется, можно этот контроль реализовать программно, например с помощью файла конфигурации. Пока такой необходимости не было.
Насчет второго замечания, не согласен. Связи ограничивать не так уж необходимо. Но если так уж хочется, можно этот контроль реализовать программно, например с помощью файла конфигурации. Пока такой необходимости не было.
+1
Кстати насчет "каждый должен через это пройти"
Опыт проектирования баз данных у меня достаточный, что бы отличить хорошее от плохого. Нужно понимать, что в данном случае БД это лишь место хранения связей объектов, для реализации паттерна "компоновщик". Вообще говоря, хранить связи можно где угодно, например в xml, просто в данном случае выбрана СУБД.
Опыт проектирования баз данных у меня достаточный, что бы отличить хорошее от плохого. Нужно понимать, что в данном случае БД это лишь место хранения связей объектов, для реализации паттерна "компоновщик". Вообще говоря, хранить связи можно где угодно, например в xml, просто в данном случае выбрана СУБД.
+1
в XML проще выразить вложенность структур, а в "двухмерной" реляционной СУБД - нет. Вот и получается что дополнительные отношения (родитель-потомок, один к одному, один ко многим) выносятся в отдельные колонки и таблицы.
-1
Угу-угу. Скажу более – вообще говоря и сами данные можно хранить где угодно. Скажем, в текстовых файлах на диске. О-очень гибко получается. Но почему-то используют СУБД. Наверное по привычке. С целью списания бюджетных средств на покупку дорогостоящих серверов баз данных. :-)
MikhailEdoshin абсолютно прав. Ваша идея имеет крайне опосредованное отношение к паттерну Composite. И по сути, она описывается одним предложением, а именно – вы вынесли хранение всех отношений предметной области один ко многим и многое-ко-многим в одну общую таблицу. Тем самым лишив сервер БД возможности полноценно поддерживать логическую целостность ваших данных (в данном случае ссылочную) и эффективно строить запросы. Поскольку логическую целостность поддерживать приходится, то вам придётся это делать руками в самом приложении. Заодно беспокоясь об изолированности транзакции и эффективности изменений данных в БД. Об эффективности написания и выполнения поисковых запросов теперь даже и упоминать неприлично.
Такие решения иногда приходится использовать, но для них нужны крайне веские основания. К примеру, если отношения между сущностями непрерывно меняются. Непрерывно, это не значит что несколько раз в месяц или год, это значит несколько раз в час или даже минуту. Скажем при проектировании некой детали в САПР системе. Но в таким случаях, как правило, и не применяют реляционные СУБД.
MikhailEdoshin абсолютно прав. Ваша идея имеет крайне опосредованное отношение к паттерну Composite. И по сути, она описывается одним предложением, а именно – вы вынесли хранение всех отношений предметной области один ко многим и многое-ко-многим в одну общую таблицу. Тем самым лишив сервер БД возможности полноценно поддерживать логическую целостность ваших данных (в данном случае ссылочную) и эффективно строить запросы. Поскольку логическую целостность поддерживать приходится, то вам придётся это делать руками в самом приложении. Заодно беспокоясь об изолированности транзакции и эффективности изменений данных в БД. Об эффективности написания и выполнения поисковых запросов теперь даже и упоминать неприлично.
Такие решения иногда приходится использовать, но для них нужны крайне веские основания. К примеру, если отношения между сущностями непрерывно меняются. Непрерывно, это не значит что несколько раз в месяц или год, это значит несколько раз в час или даже минуту. Скажем при проектировании некой детали в САПР системе. Но в таким случаях, как правило, и не применяют реляционные СУБД.
+4
Я и не призываю использовать эту схему везде. Я в статье упомянул, что даже в системе выполненной по этой схеме, некоторые части реализованы по классической. Впрочем каждый имеет право на свое мнение. Некоторые до сих пор ООП не признают, и с радостью вам докажут чем ООП плох.
0
Хотел в карму плюсик капнуть.. А оказалось уже. ;) Приятно когда не нужно выражать собственное мнение в комментариях когда оно уже выражено.
По поводу статьи - несколько не профессионально. сходя из моего опыта во всяком случае.
По поводу статьи - несколько не профессионально. сходя из моего опыта во всяком случае.
0
Ещё надо добавить, что такая схема сильно усложняет работу со стандартными ORM.
0
НЛО прилетело и опубликовало эту надпись здесь
Что за книжка "Банды четырех"?
-1
Попробую развить мысль. Если рассуждать подобным образом, то получится, что любую БД можно представить в виде одной таблицы.
Вот такие будут поля:
ObjectName - имя объекта
FieldName - имя свойства
Value - значение. Будет строковое, т.к. к строке можно привести любой тип.
В такой модели ровно те же плюсы, что и в предложенной для связей:
* Любые объекты можно добавлять произвольно, не перепроектируя БД
* Любые свойства тоже можно добавлять ничего не перепроектируя
Да и недостатки те же, ну, подумаешь, огромная таблица. Подумаешь, чуть сложнее запросы. Если где начнет тормозить - всегда можно выделить отдельную табличку для какого-нибудь конкретного объекта.
Уж не знаю, каким паттерном это назвать, но никому не кажется, что такой подход несколько ... эээ ... странный?
Вот такие будут поля:
ObjectName - имя объекта
FieldName - имя свойства
Value - значение. Будет строковое, т.к. к строке можно привести любой тип.
В такой модели ровно те же плюсы, что и в предложенной для связей:
* Любые объекты можно добавлять произвольно, не перепроектируя БД
* Любые свойства тоже можно добавлять ничего не перепроектируя
Да и недостатки те же, ну, подумаешь, огромная таблица. Подумаешь, чуть сложнее запросы. Если где начнет тормозить - всегда можно выделить отдельную табличку для какого-нибудь конкретного объекта.
Уж не знаю, каким паттерном это назвать, но никому не кажется, что такой подход несколько ... эээ ... странный?
+1
НЛО прилетело и опубликовало эту надпись здесь
Зато любое минимальное изменение требует большой затраты времени и сил при разработке. Чтоб все связи вычленить и т.п. Ну и технически, уверен, будут немереные затраты времени - для мало-мальски серьёзного запроса надо будет дцать раз связывать эту таблицу саму с собой. К тому же при строковых ключах...
0
EAV (Entity-Attribute-Value). Тоже применимый для некоторых задач паттерн. Только не для тех которые описаны в этой статье.
0
Мне одному кажется, что подобного вида решение хорошо подходит для слабоструктурированной информации, где нужно отслеживать связи данного конкретного объекта с чем-то, но при этом получение списка объектов, обладающих определенными свойствами, определенными связями или определенными связями с другими объектами с определенными свойствами (и т.д.) будет вызывать серьезные трудности?
Или еще кому-то приходила такая мысль? :)
Вообще, похоже на построение структуры БД типа "нейронная сеть".
Или еще кому-то приходила такая мысль? :)
Вообще, похоже на построение структуры БД типа "нейронная сеть".
0
Когда я учился, понятия "объектный" еще почти не было :)
А вот БД типа "нейронная сеть" уже рассматривались (и, наверное, где-то были)
Я лично никакого принципиального отличия не заметил - смысл тот же. И минусы - те же.
Мне кажется, что применение данным вещам достаточно узкое. Нейронная сеть - это то, чем человек еще пока сильно обгоняет компьютер. И по масштабам, и по скорости обращения и извлечения. И по сложности, наверное.
Компьютер же хорошо тем, что очень быстро выполняет как раз обработку однотипной структурированной информации.
2 Автор: а для чего такая реализация понадобилась? Постановка задачи?
А вот БД типа "нейронная сеть" уже рассматривались (и, наверное, где-то были)
Я лично никакого принципиального отличия не заметил - смысл тот же. И минусы - те же.
Мне кажется, что применение данным вещам достаточно узкое. Нейронная сеть - это то, чем человек еще пока сильно обгоняет компьютер. И по масштабам, и по скорости обращения и извлечения. И по сложности, наверное.
Компьютер же хорошо тем, что очень быстро выполняет как раз обработку однотипной структурированной информации.
2 Автор: а для чего такая реализация понадобилась? Постановка задачи?
0
Социальная сеть. Множество разнотипных объектов с причудливыми связями.
0
То есть, у вас можно создавать непредусмотренные вами связи прямо на лету? Пользователь взял и присоединил другого к себе не заложенными "я читаю" или "мой френд", а "я его папа"? И как они потом учитываются и обрабатываются?
+1
Да
0
Это у нас хороший диалог получился :)
И как они потом учитываются и обрабатываются?
Да
Дадите ссылку посмотреть на все это в рабочем варианте?
И как они потом учитываются и обрабатываются?
Да
Дадите ссылку посмотреть на все это в рабочем варианте?
0
Если честно, я бы сделал немного по другому.
Cделал бы "базовую" таблицу
ConnectableItem, содержащую 2 поля: Id и Type
далее все таблицы, предполагающие связи ссылаются на эту таблицу таким образом что их первичный ключ так же является и внешним.
+ делается табличка для связей ConnectableItem to ConnectableItem.
Получится более типизированно и исключит возможность появления "кривых" данных.
Cделал бы "базовую" таблицу
ConnectableItem, содержащую 2 поля: Id и Type
далее все таблицы, предполагающие связи ссылаются на эту таблицу таким образом что их первичный ключ так же является и внешним.
+ делается табличка для связей ConnectableItem to ConnectableItem.
Получится более типизированно и исключит возможность появления "кривых" данных.
0
Честно говоря не понял сути :)
0
В Вашей табличке для связей объектов идентификаторы не являются внешними ключами и теоретически могут ссылаться на несуществующие объекты.
Может возникнуть ситуация несогласованности данных что приведет к проблемам в работе кода.
Может возникнуть ситуация несогласованности данных что приведет к проблемам в работе кода.
0
Проблем быть не может, потому что для удаления объектов используется гарбиджколлектор. При удалении объекта, на самом деле объект из таблицы не удаляется, а удаляется лишь ссылка на него из твблицы GUID. Гарбиджколлектор (обычный джоб например) периодически удаляет объекты, на которые никто не ссылается. Само наличие лишних записей в БД не критично, это просто мусор который никому не мешает.
0
Мне было бы интересно узнать о подробностях реализации (разный тип связей и пр.), буду ждать продолжения.
Кстати в первом абзаце написано "писать боли".
Кстати в первом абзаце написано "писать боли".
0
Автор не совсем верно приводит описание паттерна "Composite". Далее цитата из "Шаблоны проектирования в Java. Марк Гранд".
Мотивы применения паттерна:
1. Есть сложный объект, который нужно представить в виде иерархии объектов, представляющей отношение "часть-целое".
2. Нужно свести к минимуму сложность иерархии "часть-целое", оставляя минимальным количество различных дочерних объектов, о которых должны быть осведомлены объекты дерева.
3. Не предъявляется никаких требований к большей части объектов из иерархии по их различию.
Пункты 2 и 3 накладывают серъёзные ограничения на объекты.
Мотивы применения паттерна:
1. Есть сложный объект, который нужно представить в виде иерархии объектов, представляющей отношение "часть-целое".
2. Нужно свести к минимуму сложность иерархии "часть-целое", оставляя минимальным количество различных дочерних объектов, о которых должны быть осведомлены объекты дерева.
3. Не предъявляется никаких требований к большей части объектов из иерархии по их различию.
Пункты 2 и 3 накладывают серъёзные ограничения на объекты.
0
НЛО прилетело и опубликовало эту надпись здесь
Например?
0
НЛО прилетело и опубликовало эту надпись здесь
Не стану спорить ибо это затянется. Скажу лишь что в MySQL нет контроля ссылочной целостности (по крайней мере для MyISAM) и это не мешает быть этой СУБД популярной. Наверное это о многом говорит.
-1
НЛО прилетело и опубликовало эту надпись здесь
просто завел таблицу и все заработало?
0
НЛО прилетело и опубликовало эту надпись здесь
нет. код придется написать не тот же. хотя тут все зависит от реализации и инструментария.
0
НЛО прилетело и опубликовало эту надпись здесь
я так и думал что Хибернейт :) Сам его применяю сейчас. И главное, мои компоненты они полноценные хибернейтовские энтети! Их можно использовать и так и так. Независимо от аннотаций. Согласись это гибкость и это здорово.
0
Насчет Вконтакте. Думаю что если бы они делали бы все по этой схеме, то развили бы свой сервис по функционалу раза в три быстрее, а оставшееся время кинули бы на оптимизацию узких мест и скорее всего большенство из них решили бы аппаратно, не переписывая кода. При этом куря всякие хорошие сигары и попивая сок лаймы новозеландской.
0
вот, зацените, это почти про ваш случай: http://www.simple-talk.com/community/blogs/philfactor/archive/2008/05/29/56525.aspx
еще, по мелочи, GUID глобально уникален, что следует из его названия, так что дополнительные два поля с типами в таблице связей не нужны.
еще, по мелочи, GUID глобально уникален, что следует из его названия, так что дополнительные два поля с типами в таблице связей не нужны.
0
Нужны. Иногда нужно выбрать все связанные объекты всех типов а иногда только одного.
0
просто вы аргументировали их наличие вовсе не этим, а тем, что иначе объекты не различишь.
а так - получается та самая One True Lookup Table, про которую по ссылке написано.
а так - получается та самая One True Lookup Table, про которую по ссылке написано.
0
Ну да, виноват. Тут просто двойное назначение так сказать, поэтому выбран вариант с 4-мя полями.
Кстати, спасибо за ссылку :)
Кстати, спасибо за ссылку :)
0
Добавлю ещё пару ссылок, раз уж заговорили про One True Lookup Table и Entity-Attribute-Value.
http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html
http://www.projectdmx.com/dbdesign/lookup.aspx
http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html
http://www.projectdmx.com/dbdesign/lookup.aspx
0
Это вы наступили на те грабли, которые разложили сами :)
Фактически, для решения вы вынесли в связь свойство объекта. Можно тогда и еще некоторые свойства вынести - как раз получим практически реляционную модель в перспективе :)
А не думали, что таким образом надо делать как раз очень маленькую часть? Сделать просто сквозные GIUD по всей базе, а те связи, которые требуют подобной гибкости, вынести в отдельное место? GUID_src, GIUD_dst, RelationType. Тип может иметь несколько полей, чтобы делать и "групповые" выборки? Все равно у вас вряд ли будет возможность связи типа "он мой папа" между юзером и записью в блоге :) То есть, тип связи определяет участников связи (кстати, может так же и определять "направленность": "он мой папа" - направленная связь, а "он мой брат" - двунаправленная).
Фактически, для решения вы вынесли в связь свойство объекта. Можно тогда и еще некоторые свойства вынести - как раз получим практически реляционную модель в перспективе :)
А не думали, что таким образом надо делать как раз очень маленькую часть? Сделать просто сквозные GIUD по всей базе, а те связи, которые требуют подобной гибкости, вынести в отдельное место? GUID_src, GIUD_dst, RelationType. Тип может иметь несколько полей, чтобы делать и "групповые" выборки? Все равно у вас вряд ли будет возможность связи типа "он мой папа" между юзером и записью в блоге :) То есть, тип связи определяет участников связи (кстати, может так же и определять "направленность": "он мой папа" - направленная связь, а "он мой брат" - двунаправленная).
0
Почему поля четыре? Ну 2 поля понятно, это ID связанных объектов, то есть их внешние ключи. Классическая схема - много-ко-многим. Но ведь только по ID нельзя уникально идентифицировать объект в пределах всей БД. В разных таблицах ID может повторяться (секвенция для каждой таблицы своя). Поэтому введено понятие типа объекта.
ГММММММММММММ, есть такое понятие как ЭНУМЕРАТОР) заводишь таблицу c парой полей одно из которых автоинкрементный айди другое откуда этот айди запросили и когда тебе нада получить новый ID инсертишь в эту таблицу и получаешь ID, а иначе мы в гораздо более жестких условиях, подобная архитектура весьма распространена, более того имеет смысл завести таблицу с названием типа NODES в которой хранить ноду для каждого экземпляра каждого типа контента если он может учавствовать в связях
вообще все это называется связь сущностей по графу, в отличии от менее гибких разновидностей графа таких как дерево или список
ГММММММММММММ, есть такое понятие как ЭНУМЕРАТОР) заводишь таблицу c парой полей одно из которых автоинкрементный айди другое откуда этот айди запросили и когда тебе нада получить новый ID инсертишь в эту таблицу и получаешь ID, а иначе мы в гораздо более жестких условиях, подобная архитектура весьма распространена, более того имеет смысл завести таблицу с названием типа NODES в которой хранить ноду для каждого экземпляра каждого типа контента если он может учавствовать в связях
вообще все это называется связь сущностей по графу, в отличии от менее гибких разновидностей графа таких как дерево или список
0
С такой структурой еще важно отслеживать отсутствие циклических ссылок. Если, конечно, их появление возможно на логическом уровне.
0
Что такое циклические сслыки? Много однонаправленных? Такое невозможно просто потому что в таблице GUID есть составной уникальный ключ. А ссылки туда/обратно часто наоборот полезны. Например пользователь может быть владельцем сообщества и сам же в нем и состоять.
0
ИМХО производительность будет сильно хромать. Эта таблица по опредлению узкое место в системе. Если связи между объектами постоянно меняются, то это выльется в каскад удалений и вставок. В многопользовательской системе это приведет к куче эксклюзивных блокировок. Придется держать огромное количество блокировок на строки в памяти, поскольку расширение на всю таблицу приведет к остановке работы, а это тоже ведет к падению производительности.
Какую база держит нагрузку при одновременной работе?
Какую база держит нагрузку при одновременной работе?
0
Интересно. Дайте две!
Особенно случаи, когда приходится пересаживаться на классику.
Особенно случаи, когда приходится пересаживаться на классику.
+1
Пример когда без классики сложно: деревья NestedSets (только что придумал). Или, некоторые поисковые запросы, индексация. Некие части системы, к социальной сети не относящиеся, банерокрутилка например.
Люблю такую фразу "не доводите до фанатизма". Применимо ко всему :) Так что каждая концепция должна применяться только там, где она эффективна, а не там куда её в принципе возможно приткнуть.
Люблю такую фразу "не доводите до фанатизма". Применимо ко всему :) Так что каждая концепция должна применяться только там, где она эффективна, а не там куда её в принципе возможно приткнуть.
0
Вставлю свои пять копеек, как раз сейчас занимаюсь поддержкой-разработкой продукта с подобной схемой связей.
С точки зрения программирования, с помощью такой таблицы супер-связей можно стремительно разрабатывать новые фичи продукта. Но самая жесть начинается, когда надо поддерживать существующую систему в условиях нехватки документации по связям между объектами. Зачастую, приходится логику работы связей восстанавливать по коду.
Хочется дать совет, использовать эту таблицу только для связи между крупными сущностями (типа юзер-фотка), и стараться обходиться минимальным количеством типов таких связей.
С точки зрения программирования, с помощью такой таблицы супер-связей можно стремительно разрабатывать новые фичи продукта. Но самая жесть начинается, когда надо поддерживать существующую систему в условиях нехватки документации по связям между объектами. Зачастую, приходится логику работы связей восстанавливать по коду.
Хочется дать совет, использовать эту таблицу только для связи между крупными сущностями (типа юзер-фотка), и стараться обходиться минимальным количеством типов таких связей.
0
Познавательная статейка, спасибо!
Но первые мысли после прочтения о производительности.
Что-то мне кажется если будет пару десятков тысяч записей, то начнутся жуткие тормоза.
Но первые мысли после прочтения о производительности.
Что-то мне кажется если будет пару десятков тысяч записей, то начнутся жуткие тормоза.
0
Вот так вот. Года 2 назад обдумывал и переобдумывал подобную схему. Правда, не натыкался на этот паттерн. Очень хороша показалась для гибкого построения сайтов. Я даже диплом хотел по этой теме делать :) Но именно сайтов, а не приложений. Ибо медленно будет работать очень. Все дело в том, что на логическом уровне получается сетевая БД, то есть от чего уходили - к тому и пришли. А уходили ведь не зря. Сейчас для постороения подобных схем очень хорошо подойдут ООБД.
0
Паттерн Composite применительно к БД рассматривается среди прочих в 8 главе книги Роберта Мюллера «Базы данных и UML. Проектирование».
Только к вашей архитектуре OBJ-OBJ2OBJ он не имеет никакого отношения. Правильную критику про него пишут, если у вас в СУБД нет возможности наследования, со временем разобраться в данных будет сложнее и сложнее. Мы в Афише год назад переходили с такой схемы.
Только к вашей архитектуре OBJ-OBJ2OBJ он не имеет никакого отношения. Правильную критику про него пишут, если у вас в СУБД нет возможности наследования, со временем разобраться в данных будет сложнее и сложнее. Мы в Афише год назад переходили с такой схемы.
0
И как вам переход? Куда перешли? Афиша это социальная сеть с множеством разнотипного контента? Вы уж говорите тогда посушеству, было то, такие проблемы, сделали это, проблемы пропали и т.д.
А так многие программеры хотят с чего нибудь куда нибудь перейти. Непонятно с чего и непонятно куда только.
А так многие программеры хотят с чего нибудь куда нибудь перейти. Непонятно с чего и непонятно куда только.
0
Это не социальная сеть пока, просто информационно справочный сайт.
Переход со сменой СУБД и изменением архитектуры БД был частной задачей в контексте смены архитектуры и платформы вообще. Общей задачей было обеспечить высокую скорость внесения изменений, потому была выбрана типа архитектура EAV (до меня). Я бы выбрал Core Entities & Hiers, т.к. в этой предметной области можно выделить 4 типа основных сущностей — Агенты (Люди), Произведения, Места и События. Все остальные можно описать как производные от них.
Кроме композитов Организации, Группы мест, Альбомы и Мероприятия, из-за которых меня и заинтересовал ваш пост. Нок сожалению, вы не об этом.
Переход со сменой СУБД и изменением архитектуры БД был частной задачей в контексте смены архитектуры и платформы вообще. Общей задачей было обеспечить высокую скорость внесения изменений, потому была выбрана типа архитектура EAV (до меня). Я бы выбрал Core Entities & Hiers, т.к. в этой предметной области можно выделить 4 типа основных сущностей — Агенты (Люди), Произведения, Места и События. Все остальные можно описать как производные от них.
Кроме композитов Организации, Группы мест, Альбомы и Мероприятия, из-за которых меня и заинтересовал ваш пост. Нок сожалению, вы не об этом.
0
НЛО прилетело и опубликовало эту надпись здесь
А что за модель такая "Core Entities & Hiers"?
Я знаю о ней:
1. ты ее называешь Ключевые сущности и наследники
2. тебе она нравится в последнее время
Искал в Гугле и кроме как в твоих топиках не встретил такого названия.
Она официально называется иначе? Или ты сам придумал ;)
Я знаю о ней:
1. ты ее называешь Ключевые сущности и наследники
2. тебе она нравится в последнее время
Искал в Гугле и кроме как в твоих топиках не встретил такого названия.
Она официально называется иначе? Или ты сам придумал ;)
0
Я сейчас занимаюсь созданием каталога паттернов БД. "Официальных" названий, кроме EAV, вообще в этой сфере нет, конечно приходится придумывать.
Core Entities & Hiers является обобщением более специфической модели
http://databasedesignpatterns.org/index.… , которую предложил Joe Oats.
Core Entities & Hiers является обобщением более специфической модели
http://databasedesignpatterns.org/index.… , которую предложил Joe Oats.
0
У этой архитектуры есть недостаток - два объекта могут быть связаны только одной связью.
Например, У фотографии могут быть два атрибута: кто добавил, и кто последний редактировал. Оба атрибута ссылаются на объект типа "пользователь", и оба этих пользователя могут быть одним человеком.
Добавляйте пятую колонку - тип связи. И таблицу - типы связей.
Например, У фотографии могут быть два атрибута: кто добавил, и кто последний редактировал. Оба атрибута ссылаются на объект типа "пользователь", и оба этих пользователя могут быть одним человеком.
Добавляйте пятую колонку - тип связи. И таблицу - типы связей.
+1
Спасибо за статью, идея изложена вполне "прозрачно" :) Занятный эффект получился, мне предлагали для одной задачи использовать Composite, но после прочтения вашей статьи я понял что он там не подходит.
Как говорится - "негативный результат, тоже результат".
Как говорится - "негативный результат, тоже результат".
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проектирование баз данных. Паттерн Компоновщик (Composite)