|
|
|
Хранилище произвольных данных
|
|||
|---|---|---|---|
|
#18+
Здравсвуйте. Меня интересуют подходы, паттерны, методологии разработки баз данных, которые должны содержать "произвольные наборы данных" Пример: Допустим есть две сущности - рестораны и столовые. о ресторане я хочу собирать информацию о меню, среднем чеке, скидках, еще о чем0нибудь что придет в голову. О столовых мне нужно знать есть или у повара санкнижка, где они закупают курицу на салат и что-то еще. Помимо этого я хочу еще завести себе автомамастерсие и хранить кучу параметров, относящихся к ним. Эти три сущности, в принципе, могут пересекаться по каким то там общим параметром, а могут и нет. Идея в том, что я хочу сделать хранилище некоторой разнородной информации. Какие есть на эту тему решения ? З.Ы. Если есть какое-то умное слово обозначающее данную проблему буду признателен, а то даже незнаю в какую сторону гуглить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2010, 13:52 |
|
||
|
Хранилище произвольных данных
|
|||
|---|---|---|---|
|
#18+
Не важноЭти три сущности, в принципе, могут пересекаться по каким то там общим параметром, а могут и нет. Идея в том, что я хочу сделать хранилище некоторой разнородной информации. Какие есть на эту тему решения ?Да в общем по разному делают. В РСУБД обычно есть средства, позволяющие добавлять сущности. Можно самому такое сделать, если считаете, что сделаете лучьше. Можно в XML-файле всё хранить. Расплывчатые требования... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2010, 17:36 |
|
||
|
Хранилище произвольных данных
|
|||
|---|---|---|---|
|
#18+
Умное слово EAV, паттерны реализации наследования на реляциорнных таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2010, 19:07 |
|
||
|
Хранилище произвольных данных
|
|||
|---|---|---|---|
|
#18+
В РСУБД обычно есть средства, позволяющие добавлять сущности. Можно самому такое сделать, если считаете, что сделаете лучьше. Можно в XML-файле всё хранить. Расплывчатые требования... Я, наверно, не совсем ясно донес мысль. Имеется РСУБД. Например SQL server какой-нибудь, или Оракл. Не важно. Я хочу сделать учет ресторанов тех же. Завел 20 таблиц под это. Есть таблица с интереснывми мне метриками. Пусть там есть колонки: Price, WorkTime, ПоварId. Потом я хочу еще ввести метрик. Что делать? Добавлять колонки в таблицу метрик ресторана (MenuId, AreaSize, CityId)? Можно, наверно, сделать таблицу ссылок на колонки сущности. тогда добавление метрики - это одна строка в некой таблице. Уже образовался некий паттерн. Требование, на мой взгляд, вполне четкое. Идея такая - разработать хранилище, в котором при заведении любой произвольной сущности со своим набором метрик, или добавлении любой метрики к уже существующей сущности не приходилось переделывать кардинально структуру базы и не приходилось бы каждый раз менять архитектуру приложения, работающего с этой базой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 13:16 |
|
||
|
Хранилище произвольных данных
|
|||
|---|---|---|---|
|
#18+
Не важно, слово EAV вам уже упоминали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 14:19 |
|
||
|
Хранилище произвольных данных
|
|||
|---|---|---|---|
|
#18+
Не важноВ РСУБД обычно есть средства, позволяющие добавлять сущности. Можно самому такое сделать, если считаете, что сделаете лучьше. Можно в XML-файле всё хранить. Расплывчатые требования... Я, наверно, не совсем ясно донес мысль. Имеется РСУБД. Например SQL server какой-нибудь, или Оракл. Не важно. Я хочу сделать учет ресторанов тех же. Завел 20 таблиц под это. Есть таблица с интереснывми мне метриками. Пусть там есть колонки: Price, WorkTime, ПоварId. Потом я хочу еще ввести метрик. Что делать? Добавлять колонки в таблицу метрик ресторана (MenuId, AreaSize, CityId)? Можно, наверно, сделать таблицу ссылок на колонки сущности. тогда добавление метрики - это одна строка в некой таблице. Уже образовался некий паттерн. Требование, на мой взгляд, вполне четкое. Идея такая - разработать хранилище, в котором при заведении любой произвольной сущности со своим набором метрик, или добавлении любой метрики к уже существующей сущности не приходилось переделывать кардинально структуру базы и не приходилось бы каждый раз менять архитектуру приложения, работающего с этой базой.Добавление колонки в таблицу не меняет архитектуру приложения. Иначе нужно менять программиста, если ему для добавления поля цвет нужно "всё переписывать". :-) А добавление поля в таблице - это просто добавление одной записи в таблицу метаданных. Добавление атрибута через EAV требует точно таких-же действий, как и добавление колонки - нужно определять новый атрибут (в смысле издать приказ), запрограммировать получение и обработку его в приложении и т.п. Добавлять атрибуты должен специальный человек, иначе с этими атрибутами будет бардак (что в EAV, что без EAV) На мой взгляд, идея использования EAV хороша при массовом добавлении атрибутов - например, сотни атрибутов в день, сотни тысяч атрибутов в базе. А у вас, думаю, планируется добавлять не больше нескольких атрибутов в год. Поверьте, гемороя будет больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 14:21 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=69&tid=1542498]: |
0ms |
get settings: |
8ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
61ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
| others: | 235ms |
| total: | 383ms |

| 0 / 0 |
