powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД с созданием кучи таблиц
25 сообщений из 195, страница 2 из 8
Проектирование БД с созданием кучи таблиц
    #38185459
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
по сабжу: однозначно ЕАВ.

Самая минимальная реализация ЕАВ это две(!) таблицы:

1. Древовидный список настроек и типов параметров.
2. Таблица привязки п1 к документу и хранилище значений параметров.
3. Необязательный справочник типов параметров (целое, флоат, строка, ссылка, дата и т.д.). Чисто для удобства.

Отображается в документе в виде древовидного списка атомарных значений.
При желании можно добавить таблицу, для более сложного сгруппированного отображения (н-р: "Период действия лицензии №хххх от 10-01-2005, выданной хххххх на ххххх деятельность с 01-02-2005 по 31-12-2012")

Удобно назначать права. Удобно делать выборки. Удобно реплицировать, отслеживать действия, и т.д.
Производительность будет в большинстве случаев удобоваримой.

ЗЫ: А Ваш руководитель ("предлагает при каждом создании новых типов объектов создавать новую таблицу") - дебил и дилетант. Так ему и передайте. :)
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38185665
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVоднозначно ЕАВ.
Слово "однозначно" добавляет определенный шарм этому безграмотному решению))
LSVА Ваш руководитель ("предлагает при каждом создании новых типов объектов создавать новую таблицу") - дебил и дилетант. Так ему и передайте. :)
Уже передали.
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38185971
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVСамая минимальная реализация ЕАВ это две(!) таблицы:

1. Древовидный список настроек и типов параметров.
2. Таблица привязки п1 к документу и хранилище значений параметров.
3. Необязательный справочник типов параметров (целое, флоат, строка, ссылка, дата и т.д.). Чисто для удобства.Если чем меньше таблиц, тем круче, то можно обойтись одной таблицей - древовидный справочник всего - метаданных и данных
:-)
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38185977
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot alexeyvg]LSVСамая минимальная реализация ЕАВ это две(!) таблицы...
Если чем меньше таблиц, тем круче, то можно обойтись одной таблицей - древовидный справочник всего - метаданных и данных
:-)
Круче уже только XML без единой таблицы и на флешке...
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38185995
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgLSVСамая минимальная реализация ЕАВ это две(!) таблицы:

1. Древовидный список настроек и типов параметров.
2. Таблица привязки п1 к документу и хранилище значений параметров.
3. Необязательный справочник типов параметров (целое, флоат, строка, ссылка, дата и т.д.). Чисто для удобства.Если чем меньше таблиц, тем круче, то можно обойтись одной таблицей - древовидный справочник всего - метаданных и данных
:-)А в чем тут глум ?
Дело не в том, что круче. Речь про чрезвычайную простоту реализации, доступную даже для курсача. :)
По поводу производительности - надо смотреть по постановке задачи.
Далеко не всегда экстремально высокая производительность это критично.
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38185996
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаУже передали.ТС ваш студент ???
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38186017
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVТС ваш студент ???
Ваш
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38186389
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVПо поводу производительности - надо смотреть по постановке задачи.
Далеко не всегда экстремально высокая производительность это критично.Это само собой, но из постановки задачи требуется высокая производительность, автор же писал про высказывания начальника, и не сказал, что типа "какая там производительность для наших 100 записей".

LSVА в чем тут глум ?
Дело не в том, что круче. Речь про чрезвычайную простоту реализации, доступную даже для курсача. :)Просто вы так смешно сказали про "минимальная реализация", как будто уменьшить количество таблиц == упростить систему :-)

ИМХО это сильно усложнит, будет сложнее вставлять-обновлять-выбирать... Ну зачем для EAV хранить параметры, типы и всё прочее в одной таблице, делать какие то древовидные структуры???

Проще классического EAV уж ничего не может быть: типы объектов, объекты, парметры, типы параметров, значения - итого 5 таблиц, и любое уменьшение количества таблиц усложняет систему, а не упрощает, с любой точки зркния - разработчиков, поддержки, сервера. Можно ещё сделать тип объекта и привязку параметр-тип объекта, если это нужно, это ещё 2 таблицы.
Ещё делают и больше таблиц, для реализации требуемой бизнес-логики - типа диапазонов допустимых значений и т.п., в общем, всего того, что давно реализовано в любой РСУБД.
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38186542
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
progand,

EAV, не EAV - вам NoSQL нужен
А вообще аппроксимируйте все на конечный объем данных - сомневаюсь что при громадных объемах EAV поедет так как вам нужно
Миллион разнотипных объектов точно не будет - в словаре сколько мильонов слов, а пользуемся от силы 2мя тысячами и то только самые вумные :) так и с объектами
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38187140
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну и какаято модерация или контроль типов объектов должна быть (хотя бы при помощи тэгов), а то получите кучу объектов из однотипных в результате очепяток и кривых глаз :))
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38189489
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVпо сабжу: однозначно ЕАВ.

Самая минимальная реализация ЕАВ это две(!) таблицы:

1. Древовидный список настроек и типов параметров.
2. Таблица привязки п1 к документу и хранилище значений параметров.
3. Необязательный справочник типов параметров (целое, флоат, строка, ссылка, дата и т.д.). Чисто для удобства.

Отображается в документе в виде древовидного списка атомарных значений.
При желании можно добавить таблицу, для более сложного сгруппированного отображения (н-р: "Период действия лицензии №хххх от 10-01-2005, выданной хххххх на ххххх деятельность с 01-02-2005 по 31-12-2012")

Удобно назначать права. Удобно делать выборки. Удобно реплицировать, отслеживать действия, и т.д.
Производительность будет в большинстве случаев удобоваримой.

ЗЫ: А Ваш руководитель ("предлагает при каждом создании новых типов объектов создавать новую таблицу") - дебил и дилетант. Так ему и передайте. :)

а в києві всі такі розумні?
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38189520
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
К автору, я бы создавал таблицы на каждый тип, а уж атрибуты к нему(к конкретному типу) писал бы в отдельной таблице, то есть кол-во таблиц равнялось бы:
кол-во типов * 2. Подход называется user defined attributes, если я не ошибаюсь.

ЕАВ - накладывает многие ограничения, причем не только на "производительность". Используя ЕАВ вы кладете "болт" на целостность средствами рсубд и поддерживаете ее вручную.
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38189733
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Озверин,

А в чем смысл создавать 2 таблицы вместо одной?
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38189746
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинОзверин,

А в чем смысл создавать 2 таблицы вместо одной?

Можно и одну...
Но во многих рсубд есть ограничение на кол-во столбцов.
Кроме того, изменение "на горячую" структуры таблицы может вызывать у некоторых рсубд дискомфорт.
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38189800
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинLSVпо сабжу: однозначно ЕАВ.

Самая минимальная реализация ЕАВ это две(!) таблицы:

1. Древовидный список настроек и типов параметров.
2. Таблица привязки п1 к документу и хранилище значений параметров.
3. Необязательный справочник типов параметров (целое, флоат, строка, ссылка, дата и т.д.). Чисто для удобства.

Отображается в документе в виде древовидного списка атомарных значений.
При желании можно добавить таблицу, для более сложного сгруппированного отображения (н-р: "Период действия лицензии №хххх от 10-01-2005, выданной хххххх на ххххх деятельность с 01-02-2005 по 31-12-2012")

Удобно назначать права. Удобно делать выборки. Удобно реплицировать, отслеживать действия, и т.д.
Производительность будет в большинстве случаев удобоваримой.

ЗЫ: А Ваш руководитель ("предлагает при каждом создании новых типов объектов создавать новую таблицу") - дебил и дилетант. Так ему и передайте. :)

а в києві всі такі розумні?

О! руководитель?!? :)

А по теме, боюсь что сколько будет пользователей - столько *N (сколько раз каждый пользователь будет добавлять сущности) и типов данных ... с одним набором атрибутов (а часто - одним и тем же). :)
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38189817
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинК автору, я бы создавал таблицы на каждый тип, а уж атрибуты к нему(к конкретному типу) писал бы в отдельной таблице, то есть кол-во таблиц равнялось бы:
кол-во типов * 2. Подход называется user defined attributes, если я не ошибаюсь.

ЕАВ - накладывает многие ограничения, причем не только на "производительность". Используя ЕАВ вы кладете "болт" на целостность средствами рсубд и поддерживаете ее вручную.

Я понял, почему Кот Матроскин вопрос задал




ДомКодДома ИмяДома1 ЖилойДомНаПроспектеСтачки2 ЖилойДомНаПроспектеЗорге

АтрибутыДомаКодаАтрибутуДома ИмяАтрибутаДома1 КолвоЭтажей2 НаличиеСтоянки

ЗначенияАтрибутовДомаКодДома КодАтрибута Значение115211212022-1
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38189960
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Озверин,

Вы ратуете за такую структуру? Имхо она совмещает недостатки EAV и "класссической" модели одновременно :)
1. Все равно DDL как результат действий пользователя, все равно тонны автогенеренного кода
2. все равно плохая производительность и отсутствие механизмов контроля целостности.
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38190083
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинОзверин,

Вы ратуете за такую структуру? Имхо она совмещает недостатки EAV и "класссической" модели одновременно :)
1. Все равно DDL как результат действий пользователя, все равно тонны автогенеренного кода
2. все равно плохая производительность и отсутствие механизмов контроля целостности.

Я уже сказал, какие ограничения лично меня бы заставили задуматься : оставаться ли в рамках "стандартного" подхода к проектированию:
на входе заявлено
- большое кол-во атрибутов
- пользовательское добавление их "на лету"
+ ограничение на кол-во столбцов в одной таблице(допустим, в mysql около 255 столбцов)
+ изменение структуры данных таблицы "на лету" следует уделить достаточно внимания, чтобы пользователь не "подвис" на этой операции(и не подвесил остальных)


1. Тонны кода - это ваша выдумка. Генерация таблицы пользовательского типа - примитивное действие. Второе действие - какое-нить хранение метаднных о об этих типах, при желании
2. Плохая производительность - это в каком из коней сферических?

Возьмем выборку:
Все дома со всеми атрибутами
Код: sql
1.
2.
3.
SELECT Поле1, Поле2, Поле3
FROM Дом d LEFT JOIN АтрибутыДома ad ON d.КодДома = ad.КодДома
LEFT JOIN ЗначенияАтрибутовДома AS vad ON d.КодДома = vad.КодДома AND ad.КодАтрибута = vad.КодАтрибута




VS

Все тоже самое, только с дополнительным предложением WHERE при EAV. При любой выборке в EAV всегда будет на 1 или несколько условий в WHERE больше - это же очевидно.
Что будет производительнее, угадайте? Учитывая, что индексирование значений в еав - бедовое, учитывая "разнородность" данных.

Целостность - наверное про нее придется длинный пост написать...стоит ли?
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38190112
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
т.к. типы объектов контролировать никто не будет (просто времени не хватит и людей все это модерировать) - вам таки точно подойдут всякие новомодные NoSQL (кстати они таки есть и в PostgreSQL - hstore называется)

Если бы объекты создавались бы вами на стороне разработчиков - тогда бы однозначно реляционный подход с созданием таблицы-предка Objects
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38190125
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
spт.к. типы объектов контролировать никто не будет (просто времени не хватит и людей все это модерировать) - вам таки точно подойдут всякие новомодные NoSQL (кстати они таки есть и в PostgreSQL - hstore называется)

Если бы объекты создавались бы вами на стороне разработчиков - тогда бы однозначно реляционный подход с созданием таблицы-предка Objects

причем здесь nosql вообще? Без nosql обойтись возможно, а вот иногда без sql обойтись сложно. Лучше уж осознанно выбрать nosql решение, чем потом разгребать свой выбор.
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38190225
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Озверин1. Тонны кода - это ваша выдумка.

это не выдумка, это суровая реальность.
Вот этот запросик, котоый Вы приводите - он для каждого типа обьектов свой, уникальный, никакой параметризацией этого не добиться. И процедуры добавления удаления уникальны, и бизнес-логика всякая. Придется делать механизмы автогенерации всего этого хозяйства, со всеми сопутствующими прелестями.


Озверин
Возьмем выборку:
Все дома со всеми атрибутами
Код: sql
1.
2.
3.
SELECT Поле1, Поле2, Поле3
FROM Дом d LEFT JOIN АтрибутыДома ad ON d.КодДома = ad.КодДома
LEFT JOIN ЗначенияАтрибутовДома AS vad ON d.КодДома = vad.КодДома AND ad.КодАтрибута = vad.КодАтрибута




1. что это за Поле1, Поле2, Поле3 - не вижу их у Вас в схеме?
2.Запрос "все дома со всеми атрибутами длинным датасетом имя-значение" - не будет тормозить ни здесь ни в EAV (точнее, будет тормозить одинаково на клиенте в зависимости от клиентских библиотек). Тормоза начинаются, когда возникает желание "а пусть-ка запрос у нас возвращает все обычно, по одной строке на обьект - иначе это все в гриде не отобразить". И тут Ваша структура точно так же начнет накрываться медным тазом, как и "обычный" EAV.
А если Вам так уж хочется померяться производительностью с EAV - возьмите запрос
"Все обьекты со всеми атрибутами в радиусе N от заданной точки " ;)
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38190288
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин,

а бизнес логика при "нормальном" проектировании куда денется? так, риторический вопрос
Вы структуру эту набросайте в eav и ответьте сами себе на вопрос..я не поленился..накидали иструктуру..и запросы
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38190355
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинКот Матроскин,

а бизнес логика при "нормальном" проектировании куда денется?
При "нормальном" - это при реляционном, по таблице на обьект? Да, никуда не денется - будут точно те же тысячи автогенеренных уникальных запросов и процедур.. Я же специально сгруппировал недостатки - 1 пункт - недостатки в сравнении с EAV, 2 пункт - недостатки в сравнении с реляционным подходом.
Причем плюсов по сравнению с EAV нет вообще ("меньше условий в WHERE" - это не плюс, извините), по сравнению с реляционным подходом - ну да, можно признать отсутствие необходимости в ALTER TABLE (при том что острая необходимость в изменении типов ТС-ом не оговаривалась )

ОзверинВы структуру эту набросайте в eav и ответьте сами себе на вопрос..я не поленился..накидали иструктуру..и запросы
Сало оно и есть сало, чего его пробовать EAV он и есть EAV, чего его расписывать :)
Если настаиваете, возьмем "классический" EAV c 4 таблицами ТипыОбьектов , Атрибуты , Обьекты , ЗначенияАтрибутов .
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38190670
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
progandЕсть задача хранить в базе объекты с различными атрибутами, причем будут добавляться новые типы объектов. Мне привычнее создать таблицу с id и типом объекта и таблицу с атрибутами и через таблицу связей связывать объект и его атрибуты.


Это называется EAV (entity-attribute-value).

progand Мой руководитель говорит что так будет тормозить и предлагает при каждом создании новых типов объектов создавать новую таблицу (объектов и его атрибутов).


Тормозить не будет, если всё правильно делать. Проблема в том, что делать EAV правильно сложнее, чем обычную традиционную реляционную модель. И как правило для аналитических отчётов желательно строить отдельные хранилища данных.

progand Разных типов объектов может доходить до тысячи, то есть база будет состоять из тысячи таблиц


Что тысячи -- не страшно. А вот добавляться --- уже хуже.
Тут как бы ключевой момент -- кем новые объекты должны добавляться. Если конечными пользователями -- без EAV никак.
Если вами, программистами -- ещё можно без EAV, но далее вопрос, как часто это должно происходить.
Если не часто, со скоростью разработки новых модулей системы -- можно жить и на обычной реляционой модели.
Если очень часто (типа раз в день) -- уже хуже, нужны общие подходы. Но грани опять-таки нет -- вам решать.

progandи они будут постоянно добавляться . Вряд ли будут запросы по склеиванию таблиц, но точно будут запросы которые нужно будет прогнать по всем таблицам сразу.


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

progandВ общем кол-во объектов теоретически может достигать несколько десятков миллионов. Количество типов объектов несколько тысяч. Используемая СУБД Postgresql.

Какой способ будет более правильным и быстрым?

Увы, однозначного ответа тут нет. Вам придётся думать и решать, что вам больше подходит, и что больше по душе.
Ещё раз, EAV концептуально сложнее, там всё сложнее, запросы писать сложнее и оптимизация их будет сложнее (почти наверняка
статистика для оптимизатора в 50% случаев будет бесполезна).
Но EAV -- это унификация подхода и возможность почти полной автоматизации всего программирования, хотя и в реляционной модели это возможно.

Ну и надо напомнить, что можно использовать объектно-реляционный подход отдельно и в виде гибрида с EAV -- часть данных моделировать как в рел. модели, часть -- как в EAV.

Ну и обязательно вам нужно изучить статью Анатолия Тенцера, на русском языке это стало уже "классикой" по EAV.
http://www.compress.ru/article.aspx?id=11515
...
Рейтинг: 0 / 0
Проектирование БД с созданием кучи таблиц
    #38190673
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаLSVА Ваш руководитель ("предлагает при каждом создании новых типов объектов создавать новую таблицу") - дебил и дилетант. Так ему и передайте. :)
Уже передали.

Ты штоль ?
...
Рейтинг: 0 / 0
25 сообщений из 195, страница 2 из 8
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД с созданием кучи таблиц
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]