ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД с созданием кучи таблиц
195 сообщений из 195, показаны все 8 страниц
  все  
Проектирование БД с созданием кучи таблиц
    #38184335
progand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
progand
Гость
Есть задача хранить в базе объекты с различными атрибутами, причем будут добавляться новые типы объектов. Мне привычнее создать таблицу с id и типом объекта и таблицу с атрибутами и через таблицу связей связывать объект и его атрибуты. Мой руководитель говорит что так будет тормозить и предлагает при каждом создании новых типов объектов создавать новую таблицу (объектов и его атрибутов). Разных типов объектов может доходить до тысячи, то есть база будет состоять из тысячи таблиц и они будут постоянно добавляться . Вряд ли будут запросы по склеиванию таблиц, но точно будут запросы которые нужно будет прогнать по всем таблицам сразу.

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

Какой способ будет более правильным и быстрым?
...
Рейтинг: 0 / 0
14.03.2013, 17:15
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184368
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
"серебряной пули нет"(с)
В одних случаях лучше первый способ, в других - второй. у каждого из них есть недостатки.
Если интересно почитать подробнее про преимущества и недостатки - сделайте поиск по
EAV на форуме, будете обеспечены материалом на пару месяцев чтения :)
...
Рейтинг: 0 / 0
14.03.2013, 17:29
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184381
progand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
progand
Гость
Спасибо за ответ. А можно вкратце плюсы и минусы обоих способов по вашему мнению. Надо уже срочно определиться с БД.
...
Рейтинг: 0 / 0
14.03.2013, 17:36
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184393
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Злой Бобр
Участник
progand,

Вы ТЗ озвучьте, может что и подскажем. А стрелять по воробьям лично у меня нет желания.
...
Рейтинг: 0 / 0
14.03.2013, 17:39
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184401
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
за вашего руководителя
divide et impera

Пишите (моделируете) приложение под руководством этого мудрого латинского изречения, затем смотрите в каких местах употребляете union all. это будут кандидаты на объединение.
...
Рейтинг: 0 / 0
14.03.2013, 17:45
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184410
progand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
progand
Гость
Постараюсь объяснить вкратце. Есть карта на которую пользователи могут добавлять объекты разных типов с атрибутами (например объект дом с атрибутами имя, граница, этажность, кол-во жильцов, адрес и т.д ), так же пользователь может создавать свои пользовательские типы. Так как пользователей может быть много, типов объектов тоже может быть очень много. Будут возможности выбора объектов определенного типа с различными фильтрами, а также возможность выбора объектов всех типов по определенным условиям (на пример выбрать все объекты находящиеся в определенной зоне).

И у меня встал вопрос, какая архитектура БД наиболее выгодна?
...
Рейтинг: 0 / 0
14.03.2013, 17:50
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184483
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
progandкакая архитектура БД наиболее выгодна?
В данном случае EAV рулит однозначно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 18:17
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184498
progand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
progand
Гость
Dimitry Sibiryakov, не будет ли запрос, всех объектов определенного типа с атрибутами, очень затратным по производительности в архитектуре EAV, ведь в другой архитектуре запрос будет намного быстрее, но создания для меня тысячи таблиц как-то дико.
...
Рейтинг: 0 / 0
14.03.2013, 18:29
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184501
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Злой Бобр
Участник
SERG1257,

Ну я понимаю что у вас в итоге получается многомерный массив. Но это ничего не значит. Оба подхода имеют право на существование. Другое дело что если вы упретесь по количеству запросов в производительность, то вашу схему придется полностью или частично переделывать в то что вам говорит руководитель. Поэтому смотрите на объем данных и количество запросов. Если изначально нет даже приблизительного понятия что будет, то я б строил по схеме руководителя.
...
Рейтинг: 0 / 0
14.03.2013, 18:30
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184515
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Думаете за пользователя, допрашиваете аналитиков, строите модель, обкатываете модель, но заполняете свойства определяемые пользователем нормальными таблицами. Затем добавляете EAV как дополнительные свойства.
Если вам повезет то этих дополнительных свойств, забытых в первой итерации будет немного. Если много, то следующая итерация делает их обычными полями обычных таблиц вынося из EAV.
...
Рейтинг: 0 / 0
14.03.2013, 18:39
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184574
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
progandРазных типов объектов может доходить до тысячиИ набор атрибутов у каждого уникален?
...
Рейтинг: 0 / 0
14.03.2013, 19:07
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184586
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
progandDimitry Sibiryakov, не будет ли запрос, всех объектов определенного типа с атрибутами, очень затратным по производительности в архитектуре EAV, ведь в другой архитектуре запрос будет намного быстрееСудя по описанию, запросы предполагаются несложные...

В любом случае выгоднее сделать таблицу объект с общими стрибутами, а вот для пользовательских атрибутов выбирать - EAV или таблицы. Зависит от требований к производительности (как я понимаю, это стартап, и в перспективе, буквально через полгода, так инвесторам и сказали, каждый житель земли должен занести туда все объекты реального мира, которые он когда либо видел?)

ИМХО можно делать EAV, потом пользовательские атрибуты всегда в таблицы вынести можно, когда "взлетит".
...
Рейтинг: 0 / 0
14.03.2013, 19:14
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184602
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
progandне будет ли запрос, всех объектов определенного типа с атрибутами, очень
затратным по производительности в архитектуре EAV, ведь в другой архитектуре запрос будет
намного быстрее
Код: sql
1.
select * from t where t.typ=XXX


против
Код: sql
1.
select * from t left join attr on t.id=attr.id where t.typ=XXX


при наличии индекса на attr.id будет, конечно быстрее, но эту разницу придётся
разглядывать с микроскопом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 19:23
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184724
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Dimitry Sibiryakovпри наличии индекса на attr.id будет, конечно быстрее, но эту разницу придётся
разглядывать с микроскопом.Зависит от запросов.

Если в запросе пишут attr1 = xxx and attr2 between M and K or attr2 < F
То в EAV это уже будет не очень быстро :-( Наверное, начальник это и имел в виду, а не простые выборки вида "получить один объект с всеми его атрибутами", иначе бы так не говорил.
...
Рейтинг: 0 / 0
14.03.2013, 21:04
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184726
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
alexeyvgЕсли в запросе пишут attr1 = xxx and attr2 between M and K or attr2 < F То
в EAV это уже будет не очень быстро :-(
Да неужели? С EAV это будет выглядеть примерно так же:
Код: sql
1.
2.
3.
4.
5.
(AttrType='attr1' and AttrValue = xxx) or
(AttrType='attr2' and AttrValue between M and K) or
(AttrType='attr3' and AttrValue < F)
group by id
having count(*) = 3


Индекс по AttrType,AttrValue сильно поможет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 21:12
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184751
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Dimitry SibiryakovalexeyvgЕсли в запросе пишут attr1 = xxx and attr2 between M and K or attr2 < F То
в EAV это уже будет не очень быстро :-(
Да неужели? С EAV это будет выглядеть примерно так же:
Код: sql
1.
2.
3.
4.
5.
(AttrType='attr1' and AttrValue = xxx) or
(AttrType='attr2' and AttrValue between M and K) or
(AttrType='attr3' and AttrValue < F)
group by id
having count(*) = 3



Индекс по AttrType,AttrValue сильно поможет.Да, неужели :-)

Индекс не поможет, потому что вот эти условия: "AttrType='attr1' and AttrValue = xxx" будут для трёх разных таблиц (трёх экземпляров таблицы атрибутов), и серверу нужно найти результат пересечения выборки.
Если есть 100 объектов с указанными пересечениями значений атрибутов, и по милиону объектов с этими значениями, но без пересечений, то представьте, насколько будет эффективнее составной индекс на атрибуты по сравнению с пересечением результата для каждого фильтра.
...
Рейтинг: 0 / 0
14.03.2013, 21:50
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184756
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
alexeyvgИндекс не поможет, потому что вот эти условия: "AttrType='attr1' and
AttrValue = xxx" будут для трёх разных таблиц (трёх экземпляров таблицы атрибутов)

Какой идиот разнесёт атрибуты по трём таблицам?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 21:57
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184769
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
progandЕсть задача хранить в базе объекты с различными атрибутами, причем будут добавляться новые типы объектов. Мне привычнее создать таблицу с id и типом объекта и таблицу с атрибутами и через таблицу связей связывать объект и его атрибуты. Мой руководитель говорит что так будет тормозить и предлагает при каждом создании новых типов объектов создавать новую таблицу (объектов и его атрибутов). Разных типов объектов может доходить до тысячи, то есть база будет состоять из тысячи таблиц и они будут постоянно добавляться . Вряд ли будут запросы по склеиванию таблиц, но точно будут запросы которые нужно будет прогнать по всем таблицам сразу.

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

Какой способ будет более правильным и быстрым?
Третий способ: использовать СУБД и хранить в одной "таблице".
...
Рейтинг: 0 / 0
14.03.2013, 22:14
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184776
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Dimitry SibiryakovalexeyvgИндекс не поможет, потому что вот эти условия: "AttrType='attr1' and
AttrValue = xxx" будут для трёх разных таблиц (трёх экземпляров таблицы атрибутов)

Какой идиот разнесёт атрибуты по трём таблицам?.. Спросите у специалиста по СУБД, как написать такой запрос, про который шла речь, ну и вообще про модель EAV. Только свой не показывайте, а то он тоже сделает предположение про идиота :-)
...
Рейтинг: 0 / 0
14.03.2013, 22:27
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184784
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
alexeyvgDimitry Sibiryakovпропущено...

Какой идиот разнесёт атрибуты по трём таблицам?.. Спросите у специалиста по СУБД, как написать такой запрос, про который шла речь, ну и вообще про модель EAV. Только свой не показывайте, а то он тоже сделает предположение про идиота :-)А, с having будет одна таблица, но суть от этого не меняется - всё равно будет пересечение 3-х рогромных выборок, какая разница.
...
Рейтинг: 0 / 0
14.03.2013, 22:31
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184801
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
alexeyvgбудет пересечение 3-х рогромных выборок
Это будет пересечение трёх индексных битмапов. Что гораздо меньше чем выборка.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 22:47
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184814
Фотография Шайтан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Шайтан
Участник
progand,

погугли Тенцер БД хранилище объектов

а здесь сравнение различных подходов http://www.inf.tsu.ru/library/Publications/2004/33.pdf
...
Рейтинг: 0 / 0
14.03.2013, 23:00
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184994
пролетевший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
пролетевший
Участник
Запрос с фильтрацией по атрибутам из "широкой" таблицы будет проще и быстрее чем для EAV. Хотя для UNION из 1000 таблиц да еще если с группировкой да сортировкой - это как фишка ляжет. Проблемы будут в другом:
1. Объекты определяются пользователями системы. То есть приложению нужны права на модификацию схемы, хотя бы частично. Любая дырка в безопасности типа SQL INJECTION даст полный контроль над базой. И админ нужен весьма опытный. Есть кто сумеет грамотно права распредилить ?
2. Пользователи будут создавать объекты, менять, ошибаться, переделывать. ALTER TABLE требует эксклюзивной блокировки (даже чтение блокируется ), и обычно довольно медленная, так как операция обычно редкая оптимизацией в последнюю очередь заморачиваются. То есть на редактирование система будет почти однопользовательской, пока один меняет все ждут. Несмотря на быстрое выполнение запросов.
3. На каком языке клиент ? большинство фреймворков : Java, Ruby/Rails, Django ... довольно хорошо работают с EAV, а вот для работы с редактируемыми пользователем широкими таблицами на ум ничего не приходит. Возможно весь стек доступа к базе придется писать с нуля, а это человеко-месяцы а то и годы. Ресурсы на это есть ?
4. Насколько хорошо переменная схема для бэкапов, репликации/standby ?
5. Средства ETL/отчеты - что может поддерживать динамическую схему ? И сколько придется допиливать напильником даже если есть возможность ?
6. Разработка, как такую схему данных держать в системе контроля версий, как переносить от разработчика к QA и в production ?
...
Рейтинг: 0 / 0
15.03.2013, 08:13
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38185021
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Dimitry Sibiryakovalexeyvgбудет пересечение 3-х огромных выборок
Это будет пересечение трёх индексных битмапов. Что гораздо меньше чем выборка.Понятно, не полноценная выборка, но это всё таки больше, чем поиск по индексу, причём намного, разница же в сотни, тысячи раз.
пролетевшийХотя для UNION из 1000 таблиц да еще если с группировкой да сортировкой - это как фишка ляжет.Как я понял ТС, наиболее типичными будут запросы поиска объектов одного типа по каким то условиям с аттрибутами. Ну и конечно получение одного объекта с аттрибутами по ИД.
...
Рейтинг: 0 / 0
15.03.2013, 08:49
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38185132
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
progandпредлагает при каждом создании новых типов объектов создавать новую таблицу (объектов и его атрибутов).
А кто сказал что одной таблицы будет достаточно. Объекты бывают сложные.
...
Рейтинг: 0 / 0
15.03.2013, 10:19
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38185459
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
по сабжу: однозначно ЕАВ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

Вы ратуете за такую структуру? Имхо она совмещает недостатки EAV и "класссической" модели одновременно :)
1. Все равно DDL как результат действий пользователя, все равно тонны автогенеренного кода
2. все равно плохая производительность и отсутствие механизмов контроля целостности.
...
Рейтинг: 0 / 0
19.03.2013, 15:52
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #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
19.03.2013, 16:35
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190112
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
т.к. типы объектов контролировать никто не будет (просто времени не хватит и людей все это модерировать) - вам таки точно подойдут всякие новомодные NoSQL (кстати они таки есть и в PostgreSQL - hstore называется)

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

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

причем здесь nosql вообще? Без nosql обойтись возможно, а вот иногда без sql обойтись сложно. Лучше уж осознанно выбрать nosql решение, чем потом разгребать свой выбор.
...
Рейтинг: 0 / 0
19.03.2013, 16:52
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #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
19.03.2013, 17:22
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190288
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Кот Матроскин,

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

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

ОзверинВы структуру эту набросайте в eav и ответьте сами себе на вопрос..я не поленился..накидали иструктуру..и запросы
Сало оно и есть сало, чего его пробовать EAV он и есть EAV, чего его расписывать :)
Если настаиваете, возьмем "классический" EAV c 4 таблицами ТипыОбьектов , Атрибуты , Обьекты , ЗначенияАтрибутов .
...
Рейтинг: 0 / 0
19.03.2013, 18:18
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190670
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
20.03.2013, 00:23
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190673
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
БредятинаLSVА Ваш руководитель ("предлагает при каждом создании новых типов объектов создавать новую таблицу") - дебил и дилетант. Так ему и передайте. :)
Уже передали.

Ты штоль ?
...
Рейтинг: 0 / 0
20.03.2013, 00:25
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190675
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
EAV, не EAV - вам NoSQL нужен

Ага, конечно, в любую дырку -- NoSQL затычку.

А вообще аппроксимируйте все на конечный объем данных - сомневаюсь что при громадных объемах EAV

Где там громадные-то объёмы данных ? Сказали же -- несколько миллионов.
Громадные с миллиардов начинаются.
...
Рейтинг: 0 / 0
20.03.2013, 00:28
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190680
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
ОзверинЗначенияАтрибутовДомаКодДома КодАтрибута Значение115211212022-1

Значения надо разносить ещё по типам данных, иначе будут нарушения доменной целостности, что очень плохо.
...
Рейтинг: 0 / 0
20.03.2013, 00:30
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190685
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Как я уже сказал, это требование

progandтак же пользователь может создавать свои пользовательские типы.

однозначно влечёт за собой выбор EAV в каком-то виде или хотя бы гибридной структуры EAV/реляционка.
Потому что в традиционной рел. модели пользователи не могут создавать новые объекты, добавлять к ним атрибуты.
Традиционная модель требует для этого эксклюзивной блокировки части БД.
...
Рейтинг: 0 / 0
20.03.2013, 00:36
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190686
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Dimitry SibiryakovalexeyvgЕсли в запросе пишут attr1 = xxx and attr2 between M and K or attr2 < F То
в EAV это уже будет не очень быстро :-(
Да неужели? С EAV это будет выглядеть примерно так же:
Код: sql
1.
2.
3.
4.
5.
(AttrType='attr1' and AttrValue = xxx) or
(AttrType='attr2' and AttrValue between M and K) or
(AttrType='attr3' and AttrValue < F)
group by id
having count(*) = 3


Индекс по AttrType,AttrValue сильно поможет.


Дмитрий, не так это будет в EAV, в этом -то всё и дело. В смысле -- будет проще и быстрее.
...
Рейтинг: 0 / 0
20.03.2013, 00:38
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190713
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
MasterZiv,

А зачем в каждую дырку совать ЕАВ??
у товарища ТС есть пару лет на создания поддерживающего его фреймворка??

Т.к. типы неизвестны и вообще все типо мусорка - NoSQL самое то! Любой мусор хранит и выбирает (замечу без доп затрат на N-е количество человеко лет создания фреймворков)! :)
...
Рейтинг: 0 / 0
20.03.2013, 01:43
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190842
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
MasterZiv,

Соглашусь с рекомендацией EAV, единственное что замечу, что и "реляционный" подход вполне может оказаться применимым:

там, вроде как есть отсылка к модератору создаваемых данных. Сначала пихаем то что пришло в накопительную таблицу, а уже с правами модератора (или например по факту утверждения модератором, отдельным кроновым процессом с нужными правами) делаем CREATE/ALTER TABLE... непрятность только в том, что пользователь вместо оперативной реакции на добавление должен будет увидеть что-то типа "спасибо, отправлено на модерацию"... а модератор "ок. будет добавлено в 00:00:00 при следующем прогоне."

EAV позволяет сразу показать юзверю результат того, что оно настрогало...

NoSQL - потенциально интересно, практически непонятно
... среды "ключ-значение" и? как выбрать "все типы данных в радиусе ..." разве что хранить ключи в РМД...
, а выбрать "только такие типы в радиусе"? ... хранить в РМД ключи с описаниями... ну и "нафига попу баян"? :)
...
Рейтинг: 0 / 0
20.03.2013, 08:34
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190847
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
MasterZiv,

значительно быстрее, но не совсем "проще"... хотя... писать сложные условия проверок несколько долго, но они по сути однотипны и делаются "генератором" запроса "на раз"... так что, может даже и проще. :)
...
Рейтинг: 0 / 0
20.03.2013, 08:38
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190849
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
progandТак как пользователей может быть много, типов объектов тоже может быть очень много. Будут возможности выбора объектов определенного типа с различными фильтрами,...
И у меня встал вопрос, какая архитектура БД наиболее выгодна?
А если пользователи один по смыслу тип назову по разному? Например, один напишет тип "Игла", другой "Швейная игла", девушка назовет "иголочка", чувачек назовет "иголка блин". В том чиле с ошибкимИ напишут одно и тоже имя Типа? Тогда будут возможности выбора только части подмножеств объектов одного типа? Или на это случай Вы тоже предусмотрите "фтльтр базара".
...
Рейтинг: 0 / 0
20.03.2013, 08:41
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190892
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Программист-Любитель
Участник
Без ПОТСОЯННОГО присмотра специального программиста - контролера качества данных - еав ОБЯЗАТЕЛЬНО превратится в помойку, если пользователи действительно будут добавлять новые свойства, объекты и значений.
...
Рейтинг: 0 / 0
20.03.2013, 09:19
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190929
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Программист-ЛюбительБез ПОТСОЯННОГО присмотра специального программиста - контролера качества данных - еав ОБЯЗАТЕЛЬНО превратится в помойку, если пользователи действительно будут добавлять новые свойства, объекты и значений.
"добавлять новые свойства, объекты " - обыкновенно занятие проектровщика БД. Т.е. у них пользователи могут заменять проектировщика. Почему они тада не могут заменит какого-то там программиста (пусть и специального)?
Так что, скорее всего, это для них это не вопрос.
Другое дело, еав есть еав. Все таки это заплатка, а не какая-то там типовая МД. Тут есть риски и программных ухищрений и излишенго роста энтропии проограмного обеспечения (ну типа эффектов помойки разного рода).
...
Рейтинг: 0 / 0
20.03.2013, 09:44
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38190996
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
по мне т.к. пользователи будут вводить всякий бред - модерировать его бессмысленно, так же бессмысленно плодить для этой хрени сущности.
Я бы использовал либо XML колонки для псевдосущностей или а-ля hStore (если так уж нужно выделение аттрибутов для этого мусора - хотя юзерам влом будет городить непонятные для себя штуки - им проще ввести текст скопом) - куда бы пихал весь этот бред, а попутно требовал бы ввода тегов и вот их бы и индексировал!
...
Рейтинг: 0 / 0
20.03.2013, 10:30
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38191042
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
progandВ общем кол-во объектов теоретически может достигать несколько десятков миллионов. Количество типов объектов несколько тысяч. Используемая СУБД Postgresql.
Какой способ будет более правильным и быстрым?

1) В СУБД PostgreSQL есть возможность создание своих типов
2) В СУБД PostgreSQL есть возможность создание массивов для любых типов
3) В СУБД PostgreSQL есть справочник метаданных information_schema
4) В СУБД PostgreSQL достаточно гибкий язык PL/PgSQL

Т.о. задача сводиться к... обычному менеджеру SQL ;-)
Для примера смотреть в сторону IBExpert :-)
Там просто классно сделан ввод для таблиц.
Т.е. проектируем БД, а форму ввода получаем автоматически. Правильно настраиваем индексы ;-)

Т.к. в PGAdmine уже почти все есть. Осталось по структуре БД создать автоматическую форму для ввода данных в таблицу.
...
Рейтинг: 0 / 0
20.03.2013, 10:56
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38191163
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
А зачем в каждую дырку совать ЕАВ??
у товарища ТС есть пару лет на создания поддерживающего его фреймворка??Простая, но годная для сабжа реализация ЕАВ пишется менее чем за неделю (Delphi+MSSQL).
Всего три формочки и полтора десятка SQL-ХП/ф-ций.

А вот фреймворк для 1 варианта будет с полмиллиона строк и пару человеко-лет.
И далеко не факт, что он будет работать заметно лучше ЕАВ. Если до этого вообще дойдет дело... :)
...
Рейтинг: 0 / 0
20.03.2013, 11:59
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38191786
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
LSVПростая, но годная для сабжа реализация ЕАВ пишется менее чем за неделю (Delphi+MSSQL).
А вот фреймворк для 1 варианта будет с полмиллиона строк и пару человеко-лет.
Какие-то малодостоверные оценки.

Функционал "ввода-редактирования тысячи типов" в том и в другом случае одинаков, поэтому исключается из рассмотрения. Не знаю, что Вы называете "годной для сабжа реализацией ЕАВ". Сколь мне помнится, десятки миллионов объектов множим на количество атрибутов - итого получаем под миллиард строк в СУБД. Ну что я могу сказать.... мой ноут с такой базой ощутимо тормозит. Во всяком случае, я не дам зуб, что за неделю сделаю для него хорошую реализацию. Тысяча таблиц с десятками, может сотнями тысяч строк.... да мой ноут такого даже не заметит. И я хотел бы посмотреть на архитектора, которому для этого нужно полмиллиона строк кода. Это уже напоминает фразы убойных ПМ-ов.
...
Рейтинг: 0 / 0
20.03.2013, 17:10
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38191928
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
softwarer,

+1
...
Рейтинг: 0 / 0
20.03.2013, 18:09
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192140
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
softwarerLSVПростая, но годная для сабжа реализация ЕАВ пишется менее чем за неделю (Delphi+MSSQL).
А вот фреймворк для 1 варианта будет с полмиллиона строк и пару человеко-лет.
Какие-то малодостоверные оценки.

Функционал "ввода-редактирования тысячи типов" в том и в другом случае одинаков, поэтому исключается из рассмотрения. Не знаю, что Вы называете "годной для сабжа реализацией ЕАВ". Сколь мне помнится, десятки миллионов объектов множим на количество атрибутов - итого получаем под миллиард строк в СУБД. Ну что я могу сказать.... мой ноут с такой базой ощутимо тормозит. Во всяком случае, я не дам зуб, что за неделю сделаю для него хорошую реализацию. Тысяча таблиц с десятками, может сотнями тысяч строк.... да мой ноут такого даже не заметит. И я хотел бы посмотреть на архитектора, которому для этого нужно полмиллиона строк кода. Это уже напоминает фразы убойных ПМ-ов.Какое отношение кол-во записей имеет к сложности схемы ?
Делаем справочник атрибутов (тип дома, код улицы, код города, уличный номер, площадь участка, кадастровый номер и т.д.).
Если сделать его древовидным, то можно в ГУИ красиво показывать группировать по группам атрибутов (как в инспекторе свойств).
Делаем таблицу с фактами (код объекта, код атрибута.... значение атрибута)

Вот и весь ЕАВ (упрощенно). Можно хранить хоть миллион фактов для каждого объекта.

Неужели недоходчиво объяснил ? :)
...
Рейтинг: 0 / 0
20.03.2013, 20:11
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192335
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
LSVКакое отношение кол-во записей имеет к сложности схемы ?
Никакого. Оно имеет отношение к производительности.

LSVЕсли сделать его древовидным, то можно в ГУИ красиво показывать
Возможно самая частая ошибка проектировщика - затачивание структуры данных под текущие потребности интерфейса.

LSVВот и весь ЕАВ (упрощенно). Можно хранить хоть миллион фактов для каждого объекта.
Можно. Но на моём ноуте это будет конкретно тормозить. На крутом сервере - не знаю, не рискну говорить без тестов. А вот "с тысячей таблиц" тот же самый объём данных будет летать и у меня на ноуте. Неужели недоходчиво объяснил?
...
Рейтинг: 0 / 0
20.03.2013, 23:42
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192363
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
softwarer,
А что именно будет тормозить? Запрос "все обьекты в радиусе N" будет тормозить на eav в сравнении с union по тысяче таблиц?
...
Рейтинг: 0 / 0
20.03.2013, 23:58
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192372
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Кот МатроскинА что именно будет тормозить?
"Всё", если можно так выразиться. Я просто эмпирически знаю, что в тех экспериментах, которые делаю на локале с БД - таблица в 10 млн. строк как правило устраивает меня по быстродействию, с таблицей в 100 млн. строк я, как правило, начинаю скучать.
...
Рейтинг: 0 / 0
21.03.2013, 00:03
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192488
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
softwarer,

Вы сравниваете "теплое с мягким". ОДНА таблица с 100 строк работает быстрее ДРУГОЙ ОДНОЙ таблицы с миллионом строк.

Но:

ТЫСЯЧА таблиц в ОДНОМ запросе через UNION по 100 строк - далеко не факт, что будут быстрее чем 4 таблицы (EAV) по 100 тысяч строк в ОДНОМ запросе.
...
Рейтинг: 0 / 0
21.03.2013, 06:35
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192552
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Arhat109ТЫСЯЧА таблиц в ОДНОМ запросе через UNION по 100 строк - далеко не факт, что будут быстрее чем 4 таблицы (EAV) по 100 тысяч строк в ОДНОМ запросе.
Еще может иметь значение, что SQL все же заточен под соотвествие структуры МД структуре предметной области (ПО): в списке SELECT - Колонки, FROM Таблицы - элементы стуктуры. Если в ПО есть информация Зарплата (страховой, месяц, зарплат), в МД, например, таблица Зарплата (страховой, месяц, зарплат). То запросы о зраплате всех, нескольких, за квартал, и т.п. почти на естественном языке. Для EAV даже тут ломняк думать. В более сложных случаях тем более. Учитывая, что и с ОЦ в EAV все сложнее, то в запросах, возможно, надо еще учитвать возможную большую чем в нормальной МД мусорность данных.

ПО сути EAV - это "плохая" РМД. РМД потому что там все равно таблицы, SQL и декларативный способ для реляционных БД. "Плохая", потому что нарушается требование качества структурированных МД о соотвествии структуры МД структуре ПО: 4 таблицы вместо ТЫСЯЧИ.

Вот XML, NoSQL и т.п. - там другой тип МД - не РМД. Как бы они, насколько можно, заточенный под их структурирование.

В случае ТС РМД, может быть, не совсем адекватна. Возможно, "гибридная" РМД и ЕАV все же меньшее зло чем другая МД. Однако, чистая ЕAV, скорее всего, выглядела бы привлекательно, если бы БД создавлись с целью занять персонал их набором, а извлекать информацию совсем бы не требовалось.
...
Рейтинг: 0 / 0
21.03.2013, 08:58
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192577
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
vadiminfo,

много слов "ни о чем"... EAV != РМД. Это своя МД, моделируемая в РМД небольшим набором таблиц... или большим и динамическим DDL ... или "в сочетании".

, ежели моделировать, то надо делать это "целиком" с ОЦ и т.д. и всё встает на свои места.
...
Рейтинг: 0 / 0
21.03.2013, 09:19
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192601
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Arhat109vadiminfo,

много слов "ни о чем"... EAV != РМД. Это своя МД, моделируемая в РМД небольшим набором таблиц... или большим и динамическим DDL ... или "в сочетании".

, ежели моделировать, то надо делать это "целиком" с ОЦ и т.д. и всё встает на свои места.

Мало слов ни о чем. Свои какие-то предстаывления о МД.
По типу EAV - РМД (из таблиц, SQLи деклаоатиыные ОЦ типа ключ, внешний ключ, ограниченя на значения). На Вашем языке "моделируемая в РМД ".
Конкретная МД всегда "своя". Вы бы читали внимательнее "много слов". Там было про другие типы МД типа XML.
А конкретная МД всегда "своя". Т.е. ЕАВ РМД, только "вывернутая на изнаку" как тут ея када-то спрашивали.
"динамическим DDL" это уже из области компилирования какого-то кода, что можно для любой МД. На "свои места" декларативные ОЦ в РМД встают, если с структурного соотвествия МД ПО в силу того, что их так задумал автор данного типа МД.
...
Рейтинг: 0 / 0
21.03.2013, 09:43
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192611
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Arhat109ТЫСЯЧА таблиц в ОДНОМ запросе через UNION по 100 строк - далеко не факт, что будут быстрее чем 4 таблицы (EAV) по 100 тысяч строк в ОДНОМ запросе.
Ну во-первых, скорее "4 таблицы по миллиону строк". Во-вторых - довольно близко к "факт". В-третьих же, если "запросы к тысяче таблиц" представляют собой существенную часть фунционала, скорее всего будет сделана тысяча первая "таблица с общей частью", в которую и пойдут такие запросы. Даже не потому, что так быстрее, а потому, что так удобнее.
...
Рейтинг: 0 / 0
21.03.2013, 09:48
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192698
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Arhat109... Но:
ТЫСЯЧА таблиц в ОДНОМ запросе через UNION по 100 строк - далеко не факт, что будут быстрее чем 4 таблицы (EAV) по 100 тысяч строк в ОДНОМ запросе.
Так же, вряд ли факт, что "4 таблицы (EAV) по 100 тысяч строк в одном запросе" будут быстрее, чем "одна обычная таблица" при использовании СУБД.
...
Рейтинг: 0 / 0
21.03.2013, 10:36
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192724
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoArhat109ТЫСЯЧА таблиц в ОДНОМ запросе через UNION по 100 строк - далеко не факт, что будут быстрее чем 4 таблицы (EAV) по 100 тысяч строк в ОДНОМ запросе.
Еще может иметь значение, что SQL все же заточен под соотвествие структуры МД структуре предметной области (ПО): в списке SELECT - Колонки, FROM Таблицы - элементы стуктуры. Если в ПО есть информация Зарплата (страховой, месяц, зарплат), в МД, например, таблица Зарплата (страховой, месяц, зарплат). То запросы о зраплате всех, нескольких, за квартал, и т.п. почти на естественном языке. Для EAV даже тут ломняк думать. В более сложных случаях тем более. Учитывая, что и с ОЦ в EAV все сложнее, то в запросах, возможно, надо еще учитвать возможную большую чем в нормальной МД мусорность данных.
Конечно. Но здесь опять возникает вопрос динамического изменения структуры. Про него же нельзя забывать.
vadiminfoПО сути EAV - это "плохая" РМД. РМД потому что там все равно таблицы, SQL и декларативный способ для реляционных БД. "Плохая", потому что нарушается требование качества структурированных МД о соотвествии структуры МД структуре ПО: 4 таблицы вместо ТЫСЯЧИ.
EAV и РМД - это МД хранения данных (модель нижнего уровня) в архитектуре "модель верхнего уровня+маппинг+модель нижнего уровня". И в таком контексте уже сложнее утверждать какая из моделей хранения лучше. Ведь структура, ОЦ, манипулирование поддерживаются на верхнем уровне, и на какую МД нижнего уровня "лучше" осуществлять (вынужденный, при использовании "реляционных систем") маппинг по всем этим трем аспектам, зависит, как правило, от известных проблем с динамическим изменением структуры.
И, очень важно, не смешивать две ситуации: 1000 таблиц, моделирующих 1000 разных типов сущностей, и 1000 таблиц, моделирующих один тип сущности (товар, объект на карте и т.п.) и разные его подтипы (по набору свойств).
vadiminfoВ случае ТС РМД, может быть, не совсем адекватна.
Причины? Скорее, реализация, все-таки, а вовсе не РМД. Например, РМД не накладывает ограничений на число свойств для случая "одного типа сущности". И отсутствующие значения, сами по себе, проблемой не являются.
...
Рейтинг: 0 / 0
21.03.2013, 10:52
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192728
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
softwarer скорее всего будет сделана тысяча первая "таблица с общей частью", в которую и пойдут такие запросы. Даже не потому, что так быстрее, а потому, что так удобнее.
А это ничем не поможет. Ну хорошо, Вы отберете ID-шники объектов из 1001-й таблицы - а
дальше-то что? Все атрибуты как получать? Все равно либо 1000 Union, либо 1000 left join.
...
Рейтинг: 0 / 0
21.03.2013, 10:56
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192742
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Кот МатроскинНу хорошо, Вы отберете ID-шники объектов из 1001-й таблицы - а дальше-то что? Все атрибуты как получать? Все равно либо 1000 Union, либо 1000 left join.
Мне кажется, в стремлении возразить Вы немного потеряли... задачу. Задача "получить в одной выборке все уникальные атрибуты тысячи разнородных типов объектов" - мягко говоря, нестандартна. "Дальше-то" просто ничего, как правило эта выборка и будет ответом на задачу.

Тысяча union, кстати, ничем особенно не плоха, кроме неудобного и громоздкого SQL. Технически она не так уж отличается от одной таблицы с тысячью партиций.
...
Рейтинг: 0 / 0
21.03.2013, 11:05
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192772
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
softwarer,

Если "дальше-то ничего" и атрибуты не нужны - то и в EAV запрос будет не по таблице "ЗначенияAтрибутов" с 100 миллионами строк, а только по таблице "Обьекты" c миллионом, со всеми вытекающими.
Насчет "задача нестандартна" - чего ж в ней нестандартного-то? Примерно такую штуку делают Яндекс-карты при вводе адреса дома - "в этом доме находятся...". Не рассматривайте задачу как "получить из базы выборку для грида", рассматривайте как "получить от Web-сервиса XML c обьектами".

Тысяча union, кстати, ничем особенно не плоха,

Да и отбор 1000 записей из 100 млн. "ничем особенно не плох", движок СУБД заточен
именно на такие задачи, есть механизмы оптимизации и т.д. А 1000 Union - и не оптимизировать особо никак.
...
Рейтинг: 0 / 0
21.03.2013, 11:23
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192776
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
softwarer,

Да даже по миллиону. И даже если в реализации EAV более 4-х таблиц (например по одной на тип значений). От размера таблиц скорость работы зависит в среднем логарифмически (индексы). Запросы с Union по тысяче таблиц только парсится будут "годами"... :)
и даже при наличии индексов - падение производительности надо ожидать ... линейное от количества таблиц (у каждой свой индекс).

Я взял типовую для таких решений ситуацию, когда каждый отдельный пользовательский класс фактически описывает ровно один пользовательский факт. Как только, задача ставится так как поставлена - это типовое следствие.
...
Рейтинг: 0 / 0
21.03.2013, 11:24
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192779
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаКонечно. Но здесь опять возникает вопрос динамического изменения структуры. Про него же нельзя забывать.

Структура - означет само по себе что-то статичное. Если нельзя забывать об "изменении структуры", то скорей всего, структрированные МД не очень походят. Есть, например, полустрктурированные МД типа ХМL. Ну иногда можно обойтись заплаткой типа ЕАВ, представив структуру ПО кое-где в виде данных в МД. Ну мир не всегда просто затолкать в структурированную МД. Однако, структурированными данными, манипулировать, скорее всего, легче.

БредятинаEAV и РМД - это МД хранения данных (модель нижнего уровня) в архитектуре "модель верхнего уровня+маппинг+модель нижнего уровня". И в таком контексте уже сложнее утверждать какая из моделей хранения лучше. Ведь структура, ОЦ, манипулирование поддерживаются на верхнем уровне, и на какую МД нижнего уровня "лучше" осуществлять (вынужденный, при использовании "реляционных систем") маппинг по всем этим трем аспектам, зависит, как правило, от известных проблем с динамическим изменением структуры.

Это не имеющая ничего рационального в технологиях БД пропаганда каких-то левых или искаженых понятий, скорее всего, с целью расчистить дорогу МУМПСу (мол де раз РМД МД хранения данных, то это не на моного луче МУМПСа). Например, понятие "маппинг" имеет значение, если кто-то сподобился налобать ОМД, но хочет юзать РСУБД.

"структура, ОЦ, манипулирование поддерживаются" в РМД более чем убедительно.

БредятинаПричины? ....
См. первый пункт.
...
Рейтинг: 0 / 0
21.03.2013, 11:26
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192793
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
vadiminfo,

мне сложно как-то пояснять различия между МД, {EAV | ИМД | другиеМД}, РМД и "моделированием МД в РМД" и "конкретной моделью БД" (которая "своя")... тут есть кому растолковать внятнее.

... как тут любят писать: "в архитектуре МД - маппинг - РМД", EAV занимает промежуточное (а следовательно избыточное) место. Получается архитектура "модель - маппинг - EAV - маппинг - РМД"... если в этих терминах. :)
...
Рейтинг: 0 / 0
21.03.2013, 11:33
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192848
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Arhat109мне сложно как-то пояснять различия между МД, ...

Зато это просто поясняется в толстых книгах по БД. Эти понятия и существуют для того, что упростить "пояснения"


Arhat109... как тут любят писать: "в архитектуре МД - маппинг - РМД", EAV занимает промежуточное (а следовательно избыточное) место. Получается архитектура "модель - маппинг - EAV - маппинг - РМД"... если в этих терминах. :)
А если оставить рациональную суть, как задумал Кодд, то тип МД определяется: способом структурирования, ОЦ и способом манипулирования (система запросов). Это существенное. В этом смысле EAV РМД. То что это некий подкласс МД в смысле похожих свойств по способу способу представления данных, ну так и ненормализованные или там нормализованные тоже подклассом можно считать. А так это все же конкретная МД лучше или хуже одна другой.
...
Рейтинг: 0 / 0
21.03.2013, 12:01
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192863
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoСтруктура - означает само по себе что-то статичное. Если нельзя забывать об "изменении структуры", то скорей всего, структурированные МД не очень подходят. Есть, например, полуструктурированные МД типа ХМL. Ну иногда можно обойтись заплаткой типа ЕАВ, представив структуру ПО кое-где в виде данных в МД. Ну мир не всегда просто затолкать в структурированную МД. Однако, структурированными данными, манипулировать, скорее всего, легче.
Структура является первым (из трех) аспектов любой МД (иначе, это просто не МД).
Поэтому структурированные или "полуструктурированные", все-таки, данные, а не МД.
[Да и это условность. Текст литературного произведения, например, считается "слабоструктурированными данными", но, скорее всего, в таком определении замешаны проблемы семантики, так как конструкция вполне формальная - слова и знаки пунктуации, разделенные пробелами, просто мы "не хотим" ее структурировать в БД.]
Данные структурированы и в МД верхнего уровня, и в МД нижнего уровня. И в МД "еще более нижнего уровня)) Вот как выглядит отношение со схемой {S#,NAME,STATUS,CITY}:
S4,Clark,20,London
S5,Adams,30,Athens
S2,Jones,10,Paris
S1,Smith,20,London
S3,Blake,30,Paris
а вот как выглядит его "хранение" в модели TR:
значения полей:
S1,Adams,10,Athens
S2,Blake,20,London
S3,Clark,20,London
S4,Jones,30,Paris
S5,Smith,30,Paris
таблица реконструкции:
5,4,4,5
4,5,2,4
2,2,3,1
3,1,1,2
1,3,5,3

все структурировано)
vadiminfoЭто не имеющая ничего рационального в технологиях БД пропаганда каких-то левых или искаженых понятий, скорее всего, с целью расчистить дорогу МУМПСу (мол де раз РМД МД хранения данных, то это не на моного луче МУМПСа). Например, понятие "маппинг" имеет значение, если кто-то сподобился налобать ОМД, но хочет юзать РСУБД.
Начали, вроде конструктивно, но опять ушли от сути, назвав хорошо объясненные факты (перечитайте еще раз) "не имеющей ничего рационального пропагандой")) На уровне представления пользователю, разумеется, "кто-то сподобился" показывать продаваемые товары или объекты на карте. Или накладные именно по конкретному договору, или записи конкретной накладной. То есть, типы сущностей и связи между ними. Это же очевидно)) Не хочет юзать, а вынужден использовать, потому что так научили. Это же тоже очевидно. Но РСХОД можно использовать,как применяя РМД (в классическом понимании), так и применяя РМД для реализации EAV. Обычные обоснования - ограничения РСХОД по использованию классической РМД (длина записи, "сильные блокировки" при добавлении полей и др.).
vadiminfo"структура, ОЦ, манипулирование поддерживаются" в РМД более чем убедительно.
Разумеется. Но, неизбежна МД верхнего уровня, и маппинг по всем трем аспектам. И с реализацией этой архитектуры и есть проблемы.
vadiminfoБредятинаПричины? ....
См. первый пункт.
В "первом пункте" вместо "слабоструктурированные данные" использован не корректный термин "слабоструктурированные МД". Это не ответ на вопрос почему приходится использовать EAV, моделируя ее средствами РМД.
...
Рейтинг: 0 / 0
21.03.2013, 12:09
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192876
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
vadiminfo,

конечно описано в толстых книгах... поэтому и "мне сложно"... ну не цитировать же тут! Некоторые конечно любят... :)
...
Рейтинг: 0 / 0
21.03.2013, 12:13
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38192936
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Кот МатроскинЕсли "дальше-то ничего" и атрибуты не нужны - то и в EAV запрос будет не по таблице "ЗначенияAтрибутов" с 100 миллионами строк, а только по таблице "Обьекты" c миллионом, со всеми вытекающими.
Не вижу причин оспаривать, поскольку вывод меня вполне устраивает :)

Кот Матроскин Насчет "задача нестандартна" - чего ж в ней нестандартного-то? Примерно такую штуку делают Яндекс-карты при вводе адреса дома - "в этом доме находятся...".
Кот, а Вы не пробовали запустить Яндекс-карты, посмотреть, что они делают на самом деле и перестать нелепо фантазировать? :)

Кот МатроскинНе рассматривайте задачу как "получить из базы выборку для грида", рассматривайте как "получить от Web-сервиса XML c обьектами".
А тут нет разницы. Ну ладно, допустим, Яндекс-карты работали бы так, как Вы нафантазировали. Обратились к сервису, получили от него список объектов вида id/name. При клике на объекте, если обратите внимание, идёт новый запрос к серверу, "покажи детальную информацию". Это уже ни в малейшей степени не запрос к тысяче таблиц, атрибуты идут из одной-единственной. Впрочем, я вообще не уверен, что у Яндекса для разных типов объектов заметно разные наборы атрибутов - поскольку для него аптека от школы отличается только картинкой.

Кот МатроскинДа и отбор 1000 записей из 100 млн. "ничем особенно не плох", движок СУБД заточен
Заточен. Но на моём ноуте будет работать слишком (с моей точки зрения) долго. Особенно если требуется мало-мальски нетривиальная фильтрация объектов.

Кот МатроскинА 1000 Union - и не оптимизировать особо никак.
Помнится, когда один наглый товарищ объявил себя гуру оптимизации, его попросили оптимизировать select 1 from dual.

Arhat109От размера таблиц скорость работы зависит в среднем логарифмически (индексы).
Само по себе это сферическое рассуждение в вакууме. Но более забавно то, что Вы, похоже, полагаете вычислительную сложность алгоритма единственной и всеобъемлющей характеристикой.
...
Рейтинг: 0 / 0
21.03.2013, 12:37
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193025
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
softwarerКот Матроскин Насчет "задача нестандартна" - чего ж в ней нестандартного-то? Примерно такую штуку делают Яндекс-карты при вводе адреса дома - "в этом доме находятся...".
Кот, а Вы не пробовали запустить Яндекс-карты, посмотреть, что они делают на самом деле и перестать нелепо фантазировать? :)

Пробовал - они выводят именно список обьектов. Cо всеми атрибутами или только с некоторыми (как минимум еще название, против Вашей версии "кроме ID-шников больше ничего") - вопрос итоговой верстки. Вот решат завтра спецы по интерфейсу выводить помимо названия еще часы работы сразу в списке - будем менять всю архитектуру?
"Возможно самая частая ошибка проектировщика - затачивание структуры данных под текущие потребности интерфейса" (с)

Хранит ли яндекс все в разных обьектах с разными свойствами или все сваливает в текстовое описание - опять же вопрос внутренней реализации Яндекса. ТС-у нужно хранить разные обьекты и выдавать разные обьекты, по постановке. Так что кто тут "потерял задачу" - вопрос.
...
Рейтинг: 0 / 0
21.03.2013, 13:09
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193035
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
softwarer,

Забавно, что как только кончаются аргументы - начинается бурный полет фантазии... вы где нашли то, что написали про "всеоблемлемость"? :)

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

Ещё раз: не надо сравнивать "теплое с мягким"... в смысле, что мнение, основанное на разнице работы с большой и малой ОДНОЙ таблицей, слабо применимо к оценке в текущей постановке задачи и выборе решения.
...
Рейтинг: 0 / 0
21.03.2013, 13:12
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193078
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаПоэтому структурированные или "полуструктурированные", все-таки, данные, а не МД.

Кому как. Деление МД на структурированные и слабо структурированные может позволить, что-то важное понять об оной не вникая в детали.

БредятинаНачали, вроде конструктивно, но опять ушли от сути, назвав хорошо объясненные факты (перечитайте еще раз) "не имеющей ничего рационального пропагандой"))

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

БредятинаНо РСХОД можно использовать,как применяя РМД (в классическом понимании), так и применяя РМД для реализации EAV.

Ну используйте РСХОД. Могу себе представить.
Я предпочитаю СУБД.
Зная, Ваши планы по протаскиваю МУМПСа, замечу однако, что словосочетание имеет такое значение, благодаря Ораклу, Скулю и другим успешным программным системам отнесенным к классу с именем СУБД. Если бы их назвали РСХОДом, то это словосочетание было бы раскрученным. И Вы бы теперь пытались доказать что они не РСХОД.

БредятинаНо, неизбежна МД верхнего уровня, и маппинг по всем трем аспектам. .
Ну у Вас может быть маппинг не избежен. Я с ним сталкивался тока для маппига РОЛАП на ОЛАП. В остальных случаях как-то такой неизбежности не наблюдалось.
...
Рейтинг: 0 / 0
21.03.2013, 13:24
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193158
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoБредятинаПоэтому структурированные или "полуструктурированные", все-таки, данные, а не МД.

Кому как. Деление МД на структурированные и слабо структурированные может позволить, что-то важное понять об оной не вникая в детали.
До сих пор такое деление МД было не известно в теории и практике БД. И чтобы его использовать нужны критерии . Иначе, ничего понять не удастся. Например, в структуре РМД нет связей между типами сущностей. Кто-то может это интерпретировать таким образом, что МД, в которой на уровне структуры есть связи, является более структурированной)) Поскольку Вы с этим не согласны (и, конечно, не только поэтому), нужны критерии, по которым можно было бы называть одну МД более структурированной, чем другую.
vadiminfoОдно дело начать. Другое продолжить. Это не факты, а некие представления о соотношении и способе юзание моделей.
К сожалению, это доказанные факты. Вряд ли что-то может изменить по существу, если называть факты представлениями. Разумеется, любой факт можно назвать представлением . Это же очевидно.
vadiminfoНикакой рациональной пользы от которых, скорей всего, нельзя увидеть перечитав хоть сто раз. По сравнению с Коннли, это какой-то скрежет ножем по сковордке.
Я не спорю с таким Вашим представлением. Просто прошу не отвлекаться от существа обсуждаемых вопросов. Я же не отвлекаюсь. И если критикую представление какого-либо специалиста, то только по существу.
vadiminfoНу используйте РСХОД. Могу себе представить.
Я предпочитаю СУБД.
Вы предпочитаете использовать такой термин. Я подробно объяснил, скрупулезно цитируя Дейта и др., почему "реляционные системы" не являются СУБД. Но я совершенно не возражаю, когда Вы используете аббревиатуру "СУБД". Просто потому, что все к этому привыкли. Пожалуйста, не отвлекайтесь от существа вопроса, и используйте какие угодно удобные Вам термины))
vadiminfoЗная, Ваши планы по протаскиваю МУМПСа,
Опять отвлеклись от обсуждаемых проблем. Я ни слова не говорил о MUMPS, и никаких планов у меня нет.
vadiminfo замечу однако, что словосочетание имеет такое значение, благодаря Ораклу, Скулю и другим успешным программным системам отнесенным к классу с именем СУБД.
Почему упомянутые продукты не являются СУБД я подробно объяснил. MUMPS:
1) не является СУБД;
2) и, естественно, никакой МД в этой среде нет.
Пожалуйста не отвлекайтесь от существа вопроса. В частности, Вы не объяснили по каким именно причинам приходится реализовывать на нижнем уровне EAV средствами РМД.
vadiminfoЕсли бы их назвали РСХОДом, то это словосочетание было бы раскрученным. И Вы бы теперь пытались доказать что они не РСХОД.
Здесь все знают какой я подлец. Но раз Вы начали обсуждать вопросы по существу, пожалуйста, не отвлекайтесь. Неудобно же перед людьми. LSV придется писать о десятках страниц бесполезных)) Или Вы хотите, чтобы я не мешал профессионалам обсуждать важные вопросы. Тогда так ясно и скажите.
vadiminfoНу у Вас может быть маппинг не избежен. Я с ним сталкивался тока для маппига РОЛАП на ОЛАП. В остальных случаях как-то такой неизбежности не наблюдалось.
Не наблюдалось, но делалось. Это же очевидно. Даже просто для того чтобы увидеть Фамилию вместо FirstName))
...
Рейтинг: 0 / 0
21.03.2013, 13:50
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193185
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Кот Матроскин Пробовал - они выводят именно список обьектов.
То есть не смотрели. Подсказываю: существуют инструменты, с помощью которых можно посмотреть на запросы из браузера и ответы на них сервера. В данном случае никакого "списка объектов" сервер клиенту не возвращает вообще.

Кот Матроскин(как минимум еще название, против Вашей версии "кроме ID-шников больше ничего")
Будьте так любезны не приписывайте мне результатов собственной убогой фантазии.

Кот МатроскинCо всеми атрибутами или только с некоторыми - вопрос итоговой верстки.
Слабая попытка. Впрочем, Вы по-прежнему можете попробовать назвать хотя бы одну реальную задачу, вписывающуюся в Вашу канву.

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

Кот МатроскинТС-у нужно хранить разные обьекты и выдавать разные обьекты, по постановке.
Вот и нефиг приводить как пример систему, хранящую одинаковые объекты и их вообще не выдающую (в том смысле, в котором Вы употребляете слово "выдавать").

Кот МатроскинТак что кто тут "потерял задачу" - вопрос.
Ну-ну, прямо-таки вопрос.

Arhat109Без указания конретных ограничений,
Не имеет отношения к ситуации с довольно конкретными указаниями ограничений.

Arhat109которые больше оттолкнуть не от чего как от "сложности алгоритма"
(зевая) Пара заданий в любом приличном ВУЗе:

1. Назвать алгоритмы (например, сортировки), обладающие одинаковой вычислительной сложностью и при этом кардинально отличающиеся практическим быстродействием.
2. Сконструировать ситуацию, в которой алгоритм с большей вычислительной сложностью окажется значительно быстрее алгоритма с меньшей вычислительной сложностью.

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

Arhat109вы где нашли то, что написали про "всеоблемлемость"? :)
Там, где я нашёл, что Вы не написали ни слова о действительно определяющих вещах, а упомянули только вычислительную сложность, да и в той по торопыжести допустили совершенно детскую ошибку.

Arhat109если EAV на вашем ноуте "будет сильно тормозить", то решение с кучей таблиц тормозить будет значительно сильнее. А если оно НЕ тормозит, стало быть EAV будет просто летать в тех же условиях, начиная от определенного объема данных,
Смешно. Задача: внимательно прочитать то, что Вы написали про вычислительную сложность того и другого варианта и понять, почему Ваш вывод про "тормозить-летать" - совершенно не следует из Вами же написанного 1 . Ну про соответствие практике и заикаться незачем.

1 Если честно, я не очень верю, что разум у Вас одолеет эмоции и Вы займётесь поиском ошибки. Я, конечно, могу ткнуть пальцем, но таки предпочитаю сначала надеяться на лучшее. Чтобы не так расстраивались - на моей памяти в этом форуме именно такую ошибку делают уже второй раз.
...
Рейтинг: 0 / 0
21.03.2013, 14:01
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193252
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
softwarer,

Ваша ТЗ ясна и вполне аргументирована. Но.... она имеет смысл при наличии тщательно вылизанного движка, обслуживающего сабжевые тыщи таблиц.
У Вас он есть ? Если да, то хорошо. Насколько он у Вас хорош - другой вопрос.
Что делать тем, у кого его нет ? Садиться писать на эдак парочку чел/лет ? Ради чего ????? С пушки по воробьям....

Сначала нужно убедиться что более простой путь (ЕАВ) все таки подходит/не подходит для задачи по производительности.
ИМХО, это проще, чем ваять очередной некислый по сложности движок DDL-sql, да к тому же неизвестным итоговым результатом.

Скорее всего ЕАВ для такой задачи подойдет. Если объектов 1млн. и у каждого в среднем по 100-200 свойств (да хотя бы пусть по 20 наберут !), то это немного. Скромный сервачок потянет на ура...
...
Рейтинг: 0 / 0
21.03.2013, 14:25
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193256
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
softwarerКот Матроскин Пробовал - они выводят именно список обьектов.
То есть не смотрели. Подсказываю: существуют инструменты, с помощью которых можно посмотреть на запросы из браузера и ответы на них сервера. В данном случае никакого "списка объектов" сервер клиенту не возвращает вообще.

Видите ли... в современных клиент-серверных системах отдельные части могут в разные моменты выступать как в роли клиента, так и в роли сервера.
Что список обьектов должен запросить именно браузер - я нигде не писал, будьте так любезны не приписывайте мне результатов собственной убогой фантазии (с)
В свою очередь, если список обьектов с атрибутами присутствует на страничке, которую отдали браузеру - стоит предполагать, что его-таки каким-то образом из базы извлекли. И, следовательно, задача "получить список таких обьектов с атрибутами" - не такая уж нестандартная, как кому-то казалось.

P.S. softwarer, у Вас что, критические дни? Что это за переходы на личности?
...
Рейтинг: 0 / 0
21.03.2013, 14:27
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193285
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
LSVНо.... она имеет смысл при наличии тщательно вылизанного движка, обслуживающего сабжевые тыщи таблиц.
У Вас он есть ?
Да, он называется "СУБД". Во всяком случае, я пока что не вижу, какой ещё дополнительный движок Вы имеете в виду.

Если взять постановку задачи "написать с нуля движок, который поддерживает хранение данных различных объектных типов и некий набор операций над ними", то я не вижу никаких оснований утверждать, что EAV-подход даст более компактное решение. В простых случаях они будут примерно одинаковы, по мере нарастания сложности EAV, подозреваю, начнёт кардинально проигрывать из-за сложностей с использованием стандартных механизмов СУБД.

LSVСадиться писать на эдак парочку чел/лет ? ... некислый по сложности движок DDL-sql, ....
Хм. Как бы деликатно сказать... "DDL-движок", если я правильно понимаю, о чём Вы - это задача на несколько минут, а не на несколько лет.

LSVСкромный сервачок потянет на ура...
Допускаю, что так. Поэтому и начал с "мой ноут" - если у топикстартера есть лишний сервачок адекватной мощности, то может и можно выбрать EAV.
...
Рейтинг: 0 / 0
21.03.2013, 14:37
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193317
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Кот Матроскин Что список обьектов должен запросить именно браузер - я нигде не писал,
Слабенько. Стандартный интерфейс названного Вами проекта - именно браузер. Если у Вас в кармане есть к нему другой, секретный, клиент, общающийся с сервером по другому, секретному, протоколу, и Вы "забыли упомянуть", что имеете в виду именно его.... ну ладно, показывайте этот клиент, посмотрим его

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

Кот Матроскинстоит предполагать, что его-таки каким-то образом из базы извлекли.
При этом Ваши фантазии "как именно его извлекли" - мягко говоря, малоинтересны из-за абсолютной беспочвенности. Ни Вы, ни я не можем обоснованно утверждать, что же там за фасадом. Я, например, вообще не дам зуб, что там используется реляционная СУБД.

Итого вывод: ни одного примера задачи под свою постановку Вы пока что не назвали. Единственная попытка в доступной для исследования части работает во всех смыслах иначе.

Кот Матроскин P.S. softwarer, у Вас что, критические дни? Что это за переходы на личности?
Хм. Хорошо, попробую высказаться подчёркнуто аккуратно. Вы в рамках нашей беседы несколько раз предлагали для решения простейших задач совершенно несуразные способы. По этой причине я вполне верю в то, что и правильное решение других задач Вы искренне предполагаете столь же несуразным, но я совершенно не вижу причин присоединяться к этой точке зрения и меня раздражают Ваши упорные попытки выдать эти решения за предлагаемые или предполагаемые мной.
...
Рейтинг: 0 / 0
21.03.2013, 14:48
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193360
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVВаша ТЗ ясна и вполне аргументирована. Но.... она имеет смысл при наличии тщательно вылизанного движка, обслуживающего сабжевые тыщи таблиц.
У Вас он есть ? Если да, то хорошо. Насколько он у Вас хорош - другой вопрос.
Что делать тем, у кого его нет ? Садиться писать на эдак парочку чел/лет ? Ради чего ????? С пушки по воробьям....
Еще один, весьма неожиданный, аргумент против РМД (в пользу реализации EAV средствами РМД) - классическая РМД и, что главное (!), ее реализации в РСХОД, не пригодны для поддержки "тыщи таблиц"))[/quot]
...
Рейтинг: 0 / 0
21.03.2013, 15:04
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193394
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
softwarerКот Матроскин Что список обьектов должен запросить именно браузер - я нигде не писал,
Слабенько. Стандартный интерфейс названного Вами проекта - именно браузер.

И что? в браузере список обьектов вполне виден, никакого дополнительного интерфейса не надо.
Что именно браузер запрашивает именно этот список отдельно - "Ваши убогие фантазии"(с) Я всего лишь сказал, что список запрашивается "внутри" данной системы в принципе.


softwarerКот МатроскинВ свою очередь, если список обьектов с атрибутами присутствует на страничке, которую отдали браузеру -
Ага, судя по всему, после подсказки таки посмотрели, как же работают Яндекс.Карты.

Да ясное дело, до этого даже не предполагал, что бразуер получает странички и их отображает. Только после подсказки, угу.

softwarerКот Матроскинстоит предполагать, что его-таки каким-то образом из базы извлекли.
При этом Ваши фантазии "как именно его извлекли"

Э? Я говорю, что задача такая есть . Что ее решает, в частности, проект "Яндекс-карты". Как он это делает - вопрос глубоко неважный.
Вы-то утверждали, что вообще "задача нестандартная", т.е. никому не нужна?
...
Рейтинг: 0 / 0
21.03.2013, 15:18
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193508
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Да, он называется "СУБД". Во всяком случае, я пока что не вижу, какой ещё дополнительный движок Вы имеете в виду. Хм... Удивительный ответ, учитывая реально высокий уровень Вашей квалификации и серьезность аргументов.

Хотите сказать, что для того чтобы пользователь в окошечке мог сконструировать новый атрибут, достаточно лишь СУБД ?
Никакой DDL-движок (который превратит поток сознания юзера в DDL-инструкции) не нужен ?
Вы серьезно ????
...
Рейтинг: 0 / 0
21.03.2013, 15:59
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193534
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVДа, он называется "СУБД". Во всяком случае, я пока что не вижу, какой ещё дополнительный движок Вы имеете в виду. Хм... Удивительный ответ, учитывая реально высокий уровень Вашей квалификации и серьезность аргументов.
Хотите сказать, что для того чтобы пользователь в окошечке мог сконструировать новый атрибут, достаточно лишь СУБД ? ... Вы серьезно ????
Это же очевидно. Это одно из фундаментальных отличий СУБД от СХОД
...
Рейтинг: 0 / 0
21.03.2013, 16:05
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193590
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Впрочем, я согласен, что было бы здорово, если бы пользователь не смог самостоятельно заменить батарейку в бытовом приборе (или управлять телевизором), и требовалось бы вызвать профессионала. В этом плане прочим сферам еще далеко до технологий БД. Пожалуй, только производители атомных подводных лодок и атомных электростанций добились сопоставимых с технологиями БД результатов.
...
Рейтинг: 0 / 0
21.03.2013, 16:27
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193607
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
LSVХотите сказать, что для того чтобы пользователь в окошечке мог сконструировать новый атрибут, достаточно лишь СУБД ?
Хочу сказать, что это единственная составляющая решения, заслуживающая названия "движок".

LSVНикакой DDL-движок (который превратит поток сознания юзера в DDL-инструкции) не нужен ? Вы серьезно ????
Примерно такой же, какой в случае EAV превратит этот поток сознания в DML-инструкции. Я сейчас посмотрел в свой проект, где как раз поддерживается генерация таблиц по произвольным атрибутам. Тот класс, который Вы называете "DDL-движок", занимает 105 строк вместе с комментариями. Я искренне не понимаю, как Вы собираетесь писать столь сложную и неподъёмную технологию в течение двух-трёх лет.
...
Рейтинг: 0 / 0
21.03.2013, 16:34
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193609
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
БредятинаВпрочем, я согласен, что было бы здорово, если бы пользователь не смог самостоятельно заменить батарейку в бытовом приборе (или управлять телевизором), и требовалось бы вызвать профессионала. В этом плане прочим сферам еще далеко до технологий БД. Пожалуй, только производители атомных подводных лодок и атомных электростанций добились сопоставимых с технологиями БД результатов.Ну всё.... Если ЧАЛ в топике, топик можно закрывать.
...
Рейтинг: 0 / 0
21.03.2013, 16:36
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193643
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVНу всё.... Если ЧАЛ в топике, топик можно закрывать.
Вот это достойная "пластинка" Здесь есть что сказать по существу. Вперед!
...
Рейтинг: 0 / 0
21.03.2013, 16:52
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193673
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаДо сих пор такое деление МД было не известно ...
Так Вам вроде не привыкать, что Вам многое из лекций за 3 курс до сих пор не известно.

БредятинаК сожалению, это доказанные факты. .
Если типа доказано Вами, то скорее всего, все с точностью наоборот: это не факты однозначно.


БредятинаВы предпочитаете использовать такой термин. Я подробно объяснил, скрупулезно цитируя Дейта и др., почему "реляционные системы" не являются СУБД.
У Дейта являются. Например, DB2. На той же странице, с которой Вы цитировали, но ничего не поняли. Да что говорить?
Вы же якобы ошибки у Дейта типа находили.


БредятинаОпять отвлеклись от обсуждаемых проблем. Я ни слова не говорил о MUMPS, и никаких планов у меня нет.

Ну Вы как бы пиарщик МУМПСа. Хотите перехитрить? Здесь не Балабановская спичечная фабрика. Здесь такие трюки не пройдут.


БредятинаНеудобно же перед людьми.
С Вашей то репутацией думать о неудобстве перед людьми? Шутите?


БредятинаДаже просто для того чтобы увидеть Фамилию вместо FirstName))
Напишите представление где будет Фамилию вместо FirstName.
...
Рейтинг: 0 / 0
21.03.2013, 17:05
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193723
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoТак Вам вроде не привыкать, что Вам многое из лекций за 3 курс до сих пор не известно.
Зачем же Вы, вслед за LSV, переходите на личности)) Очевидно, что это никому неизвестно. И поэтому не может быть озвучено. Никем и никогда. Но вместо того, чтобы это признать, Вы обижаетесь, и говорите, что это неизвестно только мне))
vadiminfoЕсли типа доказано Вами, то скорее всего, все с точностью наоборот: это не факты однозначно.
Нет, не мной. Я только привожу известные факты. Так что - однозначно факты, и именно поэтому Вы и обижаетесь, вместо того, чтобы говорить по существу этих фактов))
vadiminfoУ Дейта являются. Например, DB2. На той же странице, с которой Вы цитировали, но ничего не поняли. Да что говорить?
Говорить по существу. Разве я говорил, что Дейт, как и Вы, не может использовать термин СУБД для именования СХОД??? По тем же самым причинам, что и Вы))
vadiminfoВы же якобы ошибки у Дейта типа находили.
Очень серьезные. И детально показывал их суть. Не обижайтесь)) Говорите по существу. Почему нельзя использовать РМД, и приходится моделировать с ее помощью EAV. Где Вы нашли у Дейта объяснение?
vadiminfoНу Вы как бы пиарщик МУМПСа. Хотите перехитрить? Здесь не Балабановская спичечная фабрика. Здесь такие трюки не пройдут.
Пожалуйста, говорите по существу. Если хотите поговорить про MUMPS, перейдите в форум по Cache, например. Вы устраиваете провокации, а LSV, пользуясь этим, обвиняет меня в том, что я говорю не по существу, и поэтому тему можно закрывать. У него, конечно, не хватит совести сделать Вам замечание за недостойное поведение. Вы уж сами постарайтесь говорить по существу.
vadiminfoС Вашей то репутацией думать о неудобстве перед людьми? Шутите?
А зачем же Вы вступили в диалог с человеком с такой мерзкой репутацией?))
vadiminfoНапишите представление где будет Фамилию вместо FirstName.
То, что факты Вы подменяете представлениями - это уже известно. Теперь и МД верхнего уровня Вы легко заменили "представлением")) При этом Вы рады, конечно, что пользователю придется обратиться к Вам - профессионалу, даже для того, чтобы узнать фамилию)) И я тоже, в общем-то, рад за Вас. И не считаю, что Вы как-то провели пользователей. Такова технология, которую Вы используете, против которой пользователи не возражают. Они же тоже получали образование в той же системе. Все нормально.
...
Рейтинг: 0 / 0
21.03.2013, 17:27
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193756
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
БредятинаВы устраиваете провокации, а LSV, пользуясь этим, обвиняет меня в том, что я говорю не по существу,Ну так говорите по существу.
Возьмите стартовый пост и напишите аргументированную рекомендацию, как это сделал я.
Укажите плюсы, минусы.

Итак задача упрощенно: оперативно добавлять неким объектам дополнительную разнотипную инфу и далее ее анализировать.
Предлагайте конкретные решения.

...а мы заодно посмеемся. :)
...
Рейтинг: 0 / 0
21.03.2013, 17:49
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193771
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаОчевидно, что это никому неизвестно.
Если набрать в Гугле "структурированные модели данных", то выяснится что это совсем не "очевидно".

Бредятина Я только привожу известные факты.
Вы всегда приводите какую-то отсебятину.

БредятинаГоворить по существу. Разве я говорил, что Дейт, как и Вы, не может использовать термин СУБД для именования СХОД???.
Вообще-то Вы построили фразу так, что тот кто не соглашается с этим, тот не соглашается с Дейтом. А теперь выясняется, что это Вы не соглашаетесь с Дейтом? Не морочьте плиз голову.

БредятинаОчень серьезные.
Может луче начать искать ошибки у себя?


Бредятина Если хотите поговорить про MUMPS, ....

Зачем он мне то нужен? Не я же 30 лет назад выбрал его по ошибке вместо РСУБД.


БредятинаА зачем же Вы вступили в диалог с человеком с такой мерзкой репутацией?))

Вы написали ахинею на мою цитату, и не ответь я, кто-то мог подумать, что согласен с ней.

БредятинаТо, что факты Вы подменяете представлениями - это уже известно. Теперь и МД верхнего уровня Вы легко заменили "представлением")) При этом Вы рады, конечно, что пользователю придется обратиться к Вам - профессионалу, даже для того, чтобы узнать фамилию)) И я тоже, в общем-то, рад за Вас. И не считаю, что Вы как-то провели пользователей. Такова технология, которую Вы используете, против которой пользователи не возражают. Они же тоже получали образование в той же системе. Все нормально.
Судя по этому данному тексту Ваши представления о технологиях БД еще хуже, чем я думал до сих пор.
...
Рейтинг: 0 / 0
21.03.2013, 17:58
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193914
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVНу так говорите по существу.
Возьмите стартовый пост и напишите аргументированную рекомендацию, как это сделал я.
Укажите плюсы, минусы.
Пожалуйста, читайте не только свои сообщения. Я не вижу ни одного минуса в предложенном решении, если речь идет о подтипах одного типа сущности.
LSVИтак задача упрощенно: оперативно добавлять неким объектам дополнительную разнотипную инфу и далее ее анализировать.
Предлагайте конкретные решения.
...а мы заодно посмеемся. :)
Откройте тему с такой задачей. Поясните, почему именно РМД невозможно использовать. И не нужно ни над кем смеяться. Говорите конструктивно и по существу. Как Вы знаете, я всегда готов помочь с формализацией и анализом проблемы. Составим простую табличку:

№
Ситуация (задача)
Причина, по которой РМД нельзя использовать
Решение в среде "реляционной системы"
Комментарий

И давайте, сообщите данные для первой записи))
...
Рейтинг: 0 / 0
21.03.2013, 20:05
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193916
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
softwarerArhat109Без указания конретных ограничений,
Не имеет отношения к ситуации с довольно конкретными указаниями ограничений.

Какие конкретно "ограничения" указаны в поставленной задаче? Развернёте или как?
softwarerArhat109которые больше оттолкнуть не от чего как от "сложности алгоритма"
(зевая) Пара заданий в любом приличном ВУЗе:

1. Назвать алгоритмы (например, сортировки), обладающие одинаковой вычислительной сложностью и при этом кардинально отличающиеся практическим быстродействием.
2. Сконструировать ситуацию, в которой алгоритм с большей вычислительной сложностью окажется значительно быстрее алгоритма с меньшей вычислительной сложностью.

т.е. "по существу" сказать нечего, "фантазирование" замечено, начинаем "переводить стрелки" на знакомое... а по делу?

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

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

softwarerArhat109вы где нашли то, что написали про "всеоблемлемость"? :)
Там, где я нашёл, что Вы не написали ни слова о действительно определяющих вещах, а упомянули только вычислительную сложность, да и в той по торопыжести допустили совершенно детскую ошибку.

Да разве? :) "внезапно" вами забыто это:
как только на первый план выйдет "сложность алгоритма" (логарифм против линейного роста), а не проблемы с различиями в Г-реализации "прочих" частей
softwarer 1 Если честно, я не очень верю, что разум у Вас одолеет эмоции и Вы займётесь поиском ошибки. Я, конечно, могу ткнуть пальцем, но таки предпочитаю сначала надеяться на лучшее. Чтобы не так расстраивались - на моей памяти в этом форуме именно такую ошибку делают уже второй раз.

уж будьте так любезны... а то я даже и искать не собираюсь без вашей помощи... давайте вместе ещё разок посмеемся.
...
Рейтинг: 0 / 0
21.03.2013, 20:06
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193926
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Arhat109уж будьте так любезны...
Да без проблем. Прочее позволю себе поскипать, ибо по сравнению с этой Вашей ошибкой довольно скучно. Если хотите, потом с тем разберёмся.

Arhat109а то я даже и искать не собираюсь без вашей помощи...
В общем не сомневался.

давайте вместе ещё разок посмеемся.[/quot]
Да и не только вместе, присутствующие тоже поучаствуют. Итак, позволю себе кратко изложить Ваши выкладки:

1. При поиске записи в одной [большой] таблице (по индексу) вычислительная сложность этой операции O(log(N))
2. При поиске записи в куче [небольших] таблиц вычислительная сложность этой операции O(N)
3. Таким образом, по мере нарастания объёма данных первый вариант становится всё более предпочтительным ("летает") по сравнению со вторым ("тормозит").

Всё верно изложено? Есть последняя сложность подумать или хотя бы отползти.
...
Рейтинг: 0 / 0
21.03.2013, 20:15
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193934
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
softwarerВсё верно изложено? Есть последняя сложность подумать или хотя бы отползти.
Есть последняя возможность подумать или хотя бы отползти.
...
Рейтинг: 0 / 0
21.03.2013, 20:20
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193949
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoБредятинаОчевидно, что это никому неизвестно.
Если набрать в Гугле "структурированные модели данных", то выяснится что это совсем не "очевидно".
Одной этой фразой Вы поставили крест на Ваших многолетних усилиях не вдаваться в подробности, основным лейтмотивом которых было: "Если чего-то не написано в толстой книге, то это не заслуживает внимания"))

Теперь же Вы предлагаете:
1) Побывать в гостях у Славы
http://slava.fateback.com/work/docs/database/index.htm
2) Подменить структурированные типы структурированными моделями
http://citforum.ru/database/dblearn/dblearn02.shtml
3) Подменить модели структурированных данных структурированными моделями данных
http://www.math.spbu.ru/user/boris_novikov/courses/mtim3/5-semistructured.pdf
4) И т.п.
http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
http://ref.by/refs/98/24089/1.html
...
vadiminfoВы всегда приводите какую-то отсебятину.
Называть факты представлениями Вам показалось недостаточно. Добавили "отсебятину". Пожалуйста, говорите по существу.
vadiminfoВообще-то Вы построили фразу так, что тот кто не соглашается с этим, тот не соглашается с Дейтом. А теперь выясняется, что это Вы не соглашаетесь с Дейтом? Не морочьте плиз голову.
Говорите по существу. Я полностью согласен с Дейтом в части интерактивного интерфейса. И подчеркиваю, что в "реляционных системах" возможны только такие задачи для интерактивного интерфейса, о которых и пишет Дейт. Из-за неустранимых недостатков РМД. Так что, "реляционная система" в принципе не может быть СУБД. Но, Дейт, как и Вы, может называть такие системы СУБД. Как и продавцы компрессоров, имеют право называть их холодильниками. Но, в отличие от Вас с Дейтом, не называют))
vadiminfoБредятинаОчень серьезные.
Может луче начать искать ошибки у себя?
Я к этому приучен с детства. Нахожу, и исправляю. Дейт тоже исправляет (в одной из соседних тем я приводил пример с его мнением о том, что отношение может являться значением атрибута другого отношения). Но многочисленные, и очень серьезные, ошибки во всех рассуждениях о связях не исправлены в 8-м издании.
vadiminfoЗачем он мне то нужен? Не я же 30 лет назад выбрал его по ошибке вместо РСУБД.
Отлично! Вот и не говорите))
vadiminfoБредятинаА зачем же Вы вступили в диалог с человеком с такой мерзкой репутацией?))

Вы написали ахинею на мою цитату, и не ответь я, кто-то мог подумать, что согласен с ней.
Какую именно ахинею? Пожалуйста, говорите по существу, если уж приходится отвечать такому идиоту, как я.
vadiminfoСудя по этому данному тексту Ваши представления о технологиях БД еще хуже, чем я думал до сих пор.
Вы ушли даже от такого тривиального вопроса о "Фамилии". Другие участники довольно подробно обсуждают этот вопрос, и даже подсчитывают количество строк, которое нужно написать, чтобы пользователь мог бы добавить свойство "Фамилия" к типу сущности "Человек". Правда один явно говорит о разработке СУБД в среде РСХОД, для которой модель верхнего уровня осталась неизвестной, а на нижнем уровне предлагается использовать EAV. А другой говорит, что ему не составляет никакого труда реализовывать и модель верхнего уровня и EAV каждый раз в приложении. А Вы от только о моей глупости говорите, а не об обсуждаемой проблеме.
...
Рейтинг: 0 / 0
21.03.2013, 20:40
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38193993
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаОдной этой фразой Вы поставили крест
На Вашем утверждении:
БредятинаОчевидно, что это никому неизвестно.




Бредятина Но, Дейт ... может называть такие системы СУБД..
Не может а называет. На той же странице. И тем более в 8 издании на стр. 70 называет и реляционные СУБД. И перечисление тучу продуктов. Потому, плиз, не морочьте голову, приплетая Дейта к своей ахинее.

Бредятина Но многочисленные, и очень серьезные, ошибки во всех рассуждениях о связях ....
Вам бы так ошибаться.

БредятинаКакую именно ахинею?

Что-то там про РМД, которая якобы модель хранения данных, где-то там, и т.д.. Не знаю, как Вы сами еще не поняли какую именно.


БредятинаА Вы от только о моей глупости говорите, а не об обсуждаемой проблеме.
Ну как бы проблема в Вашем так сказать специфическом мышлении. Кто еще может испытывать проблемы с представлением FirstName в виде Фамилии, тем более в РМД, которая обладает мощной системой запросов?
...
Рейтинг: 0 / 0
21.03.2013, 21:28
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194186
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
softwarer,

"когда меня дополняют, я - молчу, но когда режут" (с) Барон Мюнхаузен. :)

Вы упустили один важный пункт, связанный с постановкой этой конкретной задачи, а именно: Что лучше (или - или). То есть суммарный объем информации - примерно константен. А стало быть вопрос звучит "чуть-чуть" не так:

Ваша редакция:
1. При поиске записи в одной [большой] таблице (по индексу) вычислительная сложность этой операции O(log(N))
2. При поиске записи в куче [небольших] таблиц вычислительная сложность этой операции O(N)
3. Таким образом, по мере нарастания объёма данных первый вариант становится всё более предпочтительным ("летает") по сравнению со вторым ("тормозит").

Мои утверждения:
1 пост:
Вы сравниваете "теплое с мягким" . ОДНА таблица с 100 строк работает быстрее ДРУГОЙ ОДНОЙ таблицы с миллионом строк.
(это было "теплое") Но:
ТЫСЯЧА таблиц в ОДНОМ запросе через UNION по 100 строк - далеко не факт, что будут быстрее чем 4 таблицы (EAV) по 100 тысяч строк в ОДНОМ запросе.
(а это - "мягкое")

2 пост (с оценкой сложности):
Да даже по миллиону. И даже если в реализации EAV более 4-х таблиц (например по одной на тип значений). От размера таблиц скорость работы зависит в среднем логарифмически (индексы). Запросы с Union по тысяче таблиц только парсится будут "годами"... :)
и даже при наличии индексов - падение производительности надо ожидать ... линейное от количества таблиц (у каждой свой индекс).

... найдите 2 отличия между редакциями. :)

Итого, хотите разобраться, давайте.
1. Вариант:
Имеем (пусть для определенности) 1000 таблиц по 100 записей с небольшим количеством "общих" (pos_x,pos_y,type_name, owner_id) и разным количеством (возможно и большим? давайте рандомно от 1 до 10 разных базовых типов) "почти" уникальными наборами полей (по задаче, каждый тип имеет свои атрибуты)... т.е. "объем инфы" в районе 1000*100*(4+5) = 90_000 значений атрибутов с рандомным заполнением. Начальное заполнение параметризованной процедурой, рандомно. Названия атрибутов пишем param_номер_типа_номер атрибута, где номер типа - сквозной по всем значениям всех таблиц.
2 Вариант:
То же самое, но в EAV:
Таблица всех типов: 10_000 записей.
Таблица атрибутов и их типов: 50_004 записи (4 общих).
Таблица всех значений (для простоты, всё храним как vchar): 90_000 значений.
Задача:
1. выбрать все значения всех объектов, находящиеся в квадрате {(X1,Y1),(X2Y2)} т.е. по общим атрибутам.
2. выбрать все объекты в том же квадрате, но имеющие атрибут типа "ДатаВремя" -- типа "время работы" (который в разных типах у разных пользователей может называться по-разному), со значениями заданном диапазоне...

Выкладывайте "своё" решение тут, и я выложу вам на EAV. Давайте на чистом SQL, прогоню оба на своем Мускуле. Запустим и сравним с разным объемом данных.

... тут есть ещё спецы по Каше и Мумпс (с "настоящими СУБД")... тоже можно поучаствовать.

... только сильно боюсь, что вашего решения на 1000 таблицах (впрочем как и от настоящих СУБД), врядли дождешься в этой жизни. Потому как "теоретики", блин.

ну что, будем тестить?
...
Рейтинг: 0 / 0
22.03.2013, 06:46
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194187
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Arhat109,

Да, ещё п.3. Выдать список названий и типов ВСЕХ атрибутов (полезно для интерфейса пользователю для снижения количества "поохожих" атрибутов)... как понимаете, в EAV - это просто содержимое одной таблицы.

... Ваше решение, каково? :)
...
Рейтинг: 0 / 0
22.03.2013, 06:50
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194188
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Arhat109,

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

... вы ещё по-прежнему уверены, что ваше решение точно лучше? :)
...
Рейтинг: 0 / 0
22.03.2013, 06:54
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194278
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoНа Вашем утверждении:
Не меня процитировали)) Вот мое сообщение:
Одной этой фразой Вы поставили крест на Ваших многолетних усилиях не вдаваться в подробности, основным лейтмотивом которых было: "Если чего-то не написано в толстой книге, то это не заслуживает внимания"))

Теперь же Вы предлагаете:
1) Побывать в гостях у Славы
http://slava.fateback.com/work/docs/database/index.htm
2) Подменить структурированные типы структурированными моделями
http://citforum.ru/database/dblearn/dblearn02.shtml
3) Подменить модели структурированных данных структурированными моделями данных
http://www.math.spbu.ru/user/boris_novikov/courses/mtim3/5-semistructured.pdf
4) И т.п.
http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
http://ref.by/refs/98/24089/1.html
...

Пожалуйста, поясните что такое структурированная модель данных, и, соответственно, что такое не структурированная модель данных.
vadiminfoНе может а называет. На той же странице. И тем более в 8 издании на стр. 70 называет и реляционные СУБД. И перечисление тучу продуктов. Потому, плиз, не морочьте голову, приплетая Дейта к своей ахинее.
Говорите по существу. Я полностью согласен с Дейтом в части интерактивного интерфейса. И подчеркиваю, что в "реляционных системах" возможны только такие задачи для интерактивного интерфейса, о которых и пишет Дейт. Из-за неустранимых недостатков РМД. Так что, "реляционная система" в принципе не может быть СУБД. Но, Дейт, как и Вы, может называть такие системы СУБД. Как и продавцы компрессоров, имеют право называть их холодильниками. Но, в отличие от Вас с Дейтом, не называют))
vadiminfoВам бы так ошибаться.
Говорите по существу.
Многочисленные, и очень серьезные, ошибки во всех рассуждениях о связях не исправлены у Дйта в 8-м издании.
vadiminfoЧто-то там про РМД, которая якобы модель хранения данных, где-то там, и т.д.. Не знаю, как Вы сами еще не поняли какую именно.
Говорите конкретно. Что Вы имеете в виду.
vadiminfoНу как бы проблема в Вашем так сказать специфическом мышлении. Кто еще может испытывать проблемы с представлением FirstName в виде Фамилии, тем более в РМД, которая обладает мощной системой запросов?
Говорите по существу.
Вы ушли даже от такого тривиального вопроса о "Фамилии". Другие участники довольно подробно обсуждают этот вопрос, и даже подсчитывают количество строк, которое нужно написать, чтобы пользователь мог бы добавить свойство "Фамилия" к типу сущности "Человек". Правда один явно говорит о разработке СУБД в среде РСХОД, для которой модель верхнего уровня осталась неизвестной, а на нижнем уровне предлагается использовать EAV. А другой говорит, что ему не составляет никакого труда реализовывать и модель верхнего уровня и EAV каждый раз в приложении. А Вы от только о моей глупости говорите, а не об обсуждаемой проблеме.
...
Рейтинг: 0 / 0
22.03.2013, 09:45
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194309
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Arhat109Итого, хотите разобраться, давайте.
1. Вариант:
Имеем (пусть для определенности) 1000 таблиц по 100 записей с небольшим количеством "общих" (pos_x,pos_y,type_name, owner_id) и разным количеством (возможно и большим? давайте рандомно от 1 до 10 разных базовых типов) "почти" уникальными наборами полей (по задаче, каждый тип имеет свои атрибуты)... т.е. "объем инфы" в районе 1000*100*(4+5) = 90_000 значений атрибутов с рандомным заполнением. Начальное заполнение параметризованной процедурой, рандомно. Названия атрибутов пишем param_номер_типа_номер атрибута, где номер типа - сквозной по всем значениям всех таблиц.
2 Вариант:
То же самое, но в EAV:
Таблица всех типов: 10_000 записей.
Таблица атрибутов и их типов: 50_004 записи (4 общих).
Таблица всех значений (для простоты, всё храним как vchar): 90_000 значений.
...

Очевидно, что запросы никакого значения, пока, не имеют - они могут быть какие-угодно.
Итак, в забытом Вами третьем варианте одна "нормальная таблица" с "полями" совершенно конкретных (нужных) типов. Количество полей:
4+(1000*10)=10004
Количество записей:
(1000*100)=100000
В каждой из которых максимум 14 значений полей. Итого: (100000*14)=1400000 (один миллион четыреста тысяч) значений.
Все правильно (мне кажется, у Вас какая-то путаница с расчетами)?
И что за проблемы Вы хотите выявить?
Поля нужно индексировать или, наоборот, индексов не должно быть?
...
Рейтинг: 0 / 0
22.03.2013, 10:01
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194329
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Бредятина,

никакой проблемы с расчетами. Вы, как и большинство тут - не внимательны. Вы посчитали предельный объем атрибутов, а я - средний: "максимально 10 уникальных полей"... в среднем - 5 (половина есть, половины нет).

Что хочу? Предлагаю выложить "тестовый пример" и прогнать его на одной машинке... оценить "тормоза" каждого решения. Участвовать со своей "настоящей СУБД" - будете?

Если да - от Вас контрольный пример (даже готов себе ради такого удовольствия поставить Мумпс на машинку), который можно просто залить и прогнать. Требуемые запросы к СУБД - приведены (3шт).

Если нет - ещё раз к Вам просьба: не отвечать далее на мои посты. Желательно ни прямо ни косвенно.
...
Рейтинг: 0 / 0
22.03.2013, 10:16
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194336
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Arhat109,

контрольный пример: процедура самозаполнения данными с рандомными атрибутами (как по типу данных, так и по значению) с рандомным созданием структуры для каждого типа данных. Плюс запросы (или ХП) для решения трех поставленных задач.
...
Рейтинг: 0 / 0
22.03.2013, 10:19
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194362
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Arhat109никакой проблемы с расчетами. Вы, как и большинство тут - не внимательны. Вы посчитали предельный объем атрибутов, а я - средний: "максимально 10 уникальных полей"... в среднем - 5 (половина есть, половины нет).
Где об этом написано? Я внимательно читал, не увидел про средний . Хорошо, я не внимательный.
Arhat109Что хочу? Предлагаю выложить "тестовый пример" и прогнать его на одной машинке... оценить "тормоза" каждого решения. Участвовать со своей "настоящей СУБД" - будете?
Какой пример? Я все правильно описал в своем сообщении? При чем здесь СУБД??? Можно обойтись и СХОД. В моем распоряжении нет ни СУБД, ни СХОД. Я только присоединяюсь к Вашей просьбе создать одну обыкновенную таблицу с 10004 полями и т.д. по описанию структуры БД.
Arhat109Если да - от Вас контрольный пример (даже готов себе ради такого удовольствия поставить Мумпс на машинку), который можно просто залить и прогнать. Требуемые запросы к СУБД - приведены (3шт).
То есть, и Вы можете создать эту структуру (одну таблицу) и применить к ней SQL. В чем проблема-то???
Arhat109Если нет - ещё раз к Вам просьба: не отвечать далее на мои посты. Желательно ни прямо ни косвенно.
Не хотите, не надо проверять третий вариант)) Больше не буду отвечать, конечно.
...
Рейтинг: 0 / 0
22.03.2013, 10:36
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194395
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаНе меня процитировали))


Т.е. не Вы писали:

БредятинаОчевидно, что это никому неизвестно.


А теперь, когда стало ясно, что широко известно, пытаетесь забалтывать? Дешевый прием.

БредятинаvadiminfoНе может а называет. На той же странице. И тем более в 8 издании на стр. 70 называет и реляционные СУБД. И перечисление тучу продуктов. Потому, плиз, не морочьте голову, приплетая Дейта к своей ахинее.

Говорите по существу.

А существенно только то, что Дейт считает "реляционные системы" СУБД.

На все повторы дальнейшие ответ в предыдущих постах.

Жаль, что нет ф-ии на форуме объявлять повторы троллингом, и удалять все сообщения автора за них. Это все таки слишком выходит за рамки для технических форумов.
...
Рейтинг: 0 / 0
22.03.2013, 10:52
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194411
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Бредятина,

Да "и я могу"... в т.ч. и на вашем любимом Мумпс. Но давайте, каждый сделает ТОТ пример, за который ратует. Считаете лучше - предложите пример, потестим. ЗА ВАС никто и ничего делать не будет. Не хотите делать - не отвечайте далее, как и просил ранее. Не надо флудить мне в ответ.

("внезапно" нет ни того ни другого... подозреваю, что никогда! и не было, поскольку в моем понимании, вы - "чистый теоретик" не написавший ни разу ни одной строчки кода)
...
Рейтинг: 0 / 0
22.03.2013, 11:03
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194414
Фотография Шайтан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Шайтан
Участник
ТС,вероятно, уже сдал проект заказчику и, может даже, вышел на пенсию
...
Рейтинг: 0 / 0
22.03.2013, 11:04
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194417
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Arhat109,

Да, кстати там действительно есть ошибка... в среднем будет 900_000 атрибутов. Нолик потерялся. :)
...
Рейтинг: 0 / 0
22.03.2013, 11:05
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194419
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
[quot vadiminfo]Т.е. не Вы писали:
БредятинаОчевидно, что это никому неизвестно.

Я. И это факт, который Вы подтвердили.
Вот мое сообщение:
Одной этой фразой Вы поставили крест на Ваших многолетних усилиях не вдаваться в подробности, основным лейтмотивом которых было: "Если чего-то не написано в толстой книге, то это не заслуживает внимания"))

Теперь же Вы предлагаете:
1) Побывать в гостях у Славы
http://slava.fateback.com/work/docs/database/index.htm
2) Подменить структурированные типы структурированными моделями
http://citforum.ru/database/dblearn/dblearn02.shtml
3) Подменить модели структурированных данных структурированными моделями данных
http://www.math.spbu.ru/user/boris_novikov/courses/mtim3/5-semistructured.pdf
4) И т.п.
http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
http://ref.by/refs/98/24089/1.html
...

Пожалуйста, поясните что такое структурированная модель данных, и, соответственно, что такое не структурированная модель данных.
vadiminfoА теперь, когда стало ясно, что широко известно, пытаетесь забалтывать? Дешевый прием.
Полезная самокритика)) Но, Вы же всегда пользуетесь такими приемами. В надежде на то, что здесь всем на все наплевать, и никто не станет делать запрос в google)) А я сделал и написал:
Одной этой фразой Вы поставили крест на Ваших многолетних усилиях не вдаваться в подробности, основным лейтмотивом которых было: "Если чего-то не написано в толстой книге, то это не заслуживает внимания"))

Теперь же Вы предлагаете:
1) Побывать в гостях у Славы
http://slava.fateback.com/work/docs/database/index.htm
2) Подменить структурированные типы структурированными моделями
http://citforum.ru/database/dblearn/dblearn02.shtml
3) Подменить модели структурированных данных структурированными моделями данных
http://www.math.spbu.ru/user/boris_novikov/courses/mtim3/5-semistructured.pdf
4) И т.п.
http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
http://ref.by/refs/98/24089/1.html
...

Пожалуйста, поясните что такое структурированная модель данных, и, соответственно, что такое не структурированная модель данных.
vadiminfoА существенно только то, что Дейт считает "реляционные системы" СУБД.
Будьте внимательнее, и говорите по существу. Я полностью согласен с Дейтом в части интерактивного интерфейса. И подчеркиваю, что в "реляционных системах" возможны только такие задачи для интерактивного интерфейса, о которых и пишет Дейт. Из-за неустранимых недостатков РМД. Так что, "реляционная система" в принципе не может быть СУБД. Но, Дейт, как и Вы, может называть такие системы СУБД. Как и продавцы компрессоров, имеют право называть их холодильниками. Но, в отличие от Вас с Дейтом, не называют))
vadiminfoЖаль, что нет ф-ии на форуме объявлять повторы троллингом, и удалять все сообщения автора за них. Это все таки слишком выходит за рамки для технических форумов.
Да, это было бы здорово для Вас)) Ведь Вы ушли даже от такого тривиального вопроса о "Фамилии". Другие участники довольно подробно обсуждают этот вопрос, и даже подсчитывают количество строк, которое нужно написать, чтобы пользователь мог бы добавить свойство "Фамилия" к типу сущности "Человек". Правда один явно говорит о разработке СУБД в среде РСХОД, для которой модель верхнего уровня осталась неизвестной, а на нижнем уровне предлагается использовать EAV. А другой говорит, что ему не составляет никакого труда реализовывать и модель верхнего уровня и EAV каждый раз в приложении. А Вы вот только о моей глупости говорите, а не об обсуждаемой проблеме.
Именно, постоянно выходите за рамки технических форумов.
...
Рейтинг: 0 / 0
22.03.2013, 11:05
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194420
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Шайтан,

вполне вероятно. Здесь по большей части "теоретики", причем - чистые... :)
...
Рейтинг: 0 / 0
22.03.2013, 11:05
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194431
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Arhat109Да "и я могу"... в т.ч. и на вашем любимом Мумпс.
У меня нет ничего любимого. Моя цель - максимально объективно подходить к любому вопросу.
Arhat109Но давайте, каждый сделает ТОТ пример, за который ратует. Считаете лучше - предложите пример, потестим. ЗА ВАС никто и ничего делать не будет.
Я "ратую" за все три варианта (одного и того же примера) . Это же очевидно.
Arhat109Не хотите делать - не отвечайте далее, как и просил ранее. Не надо флудить мне в ответ.
Так Вы-то зачем флудите мне в ответ???
Arhat109("внезапно" нет ни того ни другого... подозреваю, что никогда! и не было, поскольку в моем понимании, вы - "чистый теоретик" не написавший ни разу ни одной строчки кода)
Почему это "внезапно"?)) Здесь все знают, что я не написал ни одной строчки кода)) Теперь и Вы узнали.
...
Рейтинг: 0 / 0
22.03.2013, 11:11
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194511
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Бредятина,

Понял, отстал. Прежнее соглашение - в силе.
...
Рейтинг: 0 / 0
22.03.2013, 11:49
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194513
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
офф: Я так и знал. Зосрале топег личностными разборками ЧАЛ-style. :)

У меня сделано так (см. рис.)
Дерево настраивается в первой табличке (24 поля). Данные - во второй (14 полей). Большинство полей int и bool.
Нужно добавить совершенно новый параметр ? Создаем в дереве новый пункт, настраиваем нужным образом.
Потом заходим в документ (в нашем случае карточку товара), жмём "добавить", выбираем нужный параметр (новый уже виден и его можно выбрать).
Появляется диалог ввода значения. Вводим. Смотрим результат.
Доступны назначения прав на параметр (видеть/редактировать/удалять), форматирование вывода, логгирование, возможна проверка валидности значений.
Возможен поиск. Возможна ссылка на другие документы или справочники. Легко доработать для хранения произвольных BLOB-ов.
Очень просто выводить в репортах.
Для каждого типа документа свой набор параметров (для простоты. Но можно сделать общие для разных д-тов).
Ниодного DDL.
Примерно 700кБ исходников. Никаких изобретений, претензий, подвигов и чудес. :)
Уже показывал это.
Ничего не могу сказать про производительность, т.к. у меня пока нет млн.строк. Тестить лениво. :)
Можно ли это назвать простеньким движком ? Вполне, ИМХО.

Как можно подобное уложить в 150 строк - ума не приложу. :)

Хотелось бы посмотреть, как что-то подобное реализуют коллеги.
...
Рейтинг: 0 / 0
22.03.2013, 11:50
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194540
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаЯ. И это факт, который Вы подтвердили.


И вот еще, пример, подтверждение пример "факта" (что никому не известнно что про структурированные МД) для особо сообразительных (до которых долго доходят давно известные избитые весчи)

http://www.kgau.ru/istiki/is/ch02.html#teis_kaga2_2

В завершение общения с ЧАЛом не могу удержаться, и есче раз не поржать над чтением ЧАЛом Дейта и попытками приплести последнего к тому, что "реляционные системы не СУБД".
Это отжиг так отжиг.

Тому кто не знает ЧАЛа скажу, что любимый способ "Доказательства" - повтор. Оппоненту надоест отвечать - и тада "мы видим что возражений нет" или что-то подобное подразумевается.
...
Рейтинг: 0 / 0
22.03.2013, 11:57
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194574
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoИ вот еще, пример, подтверждение пример "факта" (что никому не известнно что про структурированные МД) для особо сообразительных (до которых долго доходят давно известные избитые весчи)
http://www.kgau.ru/istiki/is/ch02.html#teis_kaga2_2
К сожалению, Google Chrome не может открыть страницу www.kgau.ru.
Поэтому, поясните,пожалуйста Вашу позицию по ссылкам, полученным в точности по предложенному Вами запросу.
Вот мое сообщение:
Одной этой фразой Вы поставили крест на Ваших многолетних усилиях не вдаваться в подробности, основным лейтмотивом которых было: "Если чего-то не написано в толстой книге, то это не заслуживает внимания"))

Теперь же Вы предлагаете:
1) Побывать в гостях у Славы
http://slava.fateback.com/work/docs/database/index.htm
2) Подменить структурированные типы структурированными моделями
http://citforum.ru/database/dblearn/dblearn02.shtml
3) Подменить модели структурированных данных структурированными моделями данных
http://www.math.spbu.ru/user/boris_novikov/courses/mtim3/5-semistructured.pdf
4) И т.п.
http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
http://ref.by/refs/98/24089/1.html
...

Пожалуйста, поясните что такое структурированная модель данных, и, соответственно, что такое не структурированная модель данных.
vadiminfoВ завершение общения с ЧАЛом не могу удержаться, и есче раз не поржать над чтением ЧАЛом Дейта и попытками приплести последнего к тому, что "реляционные системы не СУБД".
Это отжиг так отжиг.
Пожалуйста, говорите по существу. Я полностью согласен с Дейтом в части интерактивного интерфейса. И подчеркиваю, что в "реляционных системах" возможны только такие задачи для интерактивного интерфейса, о которых и пишет Дейт. Из-за неустранимых недостатков РМД. Так что, "реляционная система" в принципе не может быть СУБД. Но, Дейт, как и Вы, может называть такие системы СУБД. Как и продавцы компрессоров, имеют право называть их холодильниками. Но, в отличие от Вас с Дейтом, не называют))
vadiminfoТому кто не знает ЧАЛа скажу, что любимый способ "Доказательства" - повтор. Оппоненту надоест отвечать - и тада "мы видим что возражений нет" или что-то подобное подразумевается.
Так вот и ответьте по существу. Вы еще ни разу не ответили. Вы ушли даже от такого тривиального вопроса о "Фамилии". Другие участники довольно подробно обсуждают этот вопрос, и даже подсчитывают количество строк, которое нужно написать, чтобы пользователь мог бы добавить свойство "Фамилия" к типу сущности "Человек". Правда один явно говорит о разработке СУБД в среде РСХОД, для которой модель верхнего уровня осталась неизвестной, а на нижнем уровне предлагается использовать EAV. А другой говорит, что ему не составляет никакого труда реализовывать и модель верхнего уровня и EAV каждый раз в приложении. А Вы вот только о моей глупости говорите, а не об обсуждаемой проблеме.
Именно Вы постоянно выходите за рамки технических форумов.
...
Рейтинг: 0 / 0
22.03.2013, 12:12
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194602
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVУ меня сделано так (см. рис.)
Это:
1) Описать новое свойство типа сущности.
2) Описать доступ к нему (или просто добавить в интерфейсе типа сущности).
3) Вводить значения и делать запросы.
применимо ко всем трем рассматриваемым вариантам.
Или Вы хотите рассказать о четвертом варианте. Или о подварианте второго (EAV) варианта?
Напомню их, на всякий случай:
Вариант 1. Классическая РМД с наследованием общих свойств (?) и отдельной таблицей на "специфические" свойства типа сущности. Здесь возникает вопрос о "масштабе специфичности". Свойство может принадлежать многим подтипам.
Вариант 2. EAV.
2.1. Разновидность 1. Требуется описание.
2.2. Разновидность 2. Требуется описание.
...
2.n. Разновидность n. Требуется описание.
Вариант 3. Классическая РМД с одной таблицей.
...
Рейтинг: 0 / 0
22.03.2013, 12:21
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194604
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Бредятина,

Когда будет "по существу" ? Срач в топике реально поднадоел всем, кроме Вас...

Конкретно что можете посоветовать ТС-у (см. стартовый пост).
Что ТС должен сделать для реализации ? Какова ожидаемая трудоёмкость ?
...
Рейтинг: 0 / 0
22.03.2013, 12:22
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194641
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Классическая РМД с наследованием общих свойств (?) и отдельной таблицей на "специфические" свойства типа сущности. Здесь возникает вопрос о "масштабе специфичности". Свойство может принадлежать многим подтипам.Тут много "но".
Кто даст гарантию, что свойство общее абсолютно для всех типов сущности ? Что делать, если позже окажется, что свойство не может быть общим для некоторых параметров.
Получается, что все свойства должны лежать в отдельной таблице, чтоб унифицировать выборки. Разве это не разновидность реализации ЕАВ ?

Пожалуй невозможно сделать чистые вар.1 или вар. 2.
У обоих вариантов будут элементы др. друга. Только пропорции разные и трудоемкость реализации.
...
Рейтинг: 0 / 0
22.03.2013, 12:34
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194650
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVБредятина,
Когда будет "по существу" ? Срач в топике реально поднадоел всем, кроме Вас...
Конкретно что можете посоветовать ТС-у (см. стартовый пост).
Что ТС должен сделать для реализации ? Какова ожидаемая трудоёмкость ?
Вы прекрасно знаете, что я всегда говорю только по существу. Вот мое сообщение:
Это:
1) Описать новое свойство типа сущности.
2) Описать доступ к нему (или просто добавить в интерфейсе типа сущности).
3) Вводить значения и делать запросы.
применимо ко всем трем рассматриваемым вариантам.
Или Вы хотите рассказать о четвертом варианте. Или о подварианте второго (EAV) варианта?
Напомню их, на всякий случай:
Вариант 1. Классическая РМД с наследованием общих свойств (?) и отдельной таблицей на "специфические" свойства типа сущности. Здесь возникает вопрос о "масштабе специфичности". Свойство может принадлежать многим подтипам.
Вариант 2. EAV.
2.1. Разновидность 1. Требуется описание.
2.2. Разновидность 2. Требуется описание.
...
2.n. Разновидность n. Требуется описание.
Вариант 3. Классическая РМД с одной таблицей.
...
Рейтинг: 0 / 0
22.03.2013, 12:38
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194674
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVТут много "но".
Посмотрим...
LSVКто даст гарантию, что свойство общее абсолютно для всех типов сущности ? Что делать, если позже окажется, что свойство не может быть общим для некоторых параметров.
Это я уже написал в комментарии к первому варианту. Не вижу никаких "но" по этому комментарию.
LSVПолучается, что все свойства должны лежать в отдельной таблице, чтоб унифицировать выборки. Разве это не разновидность реализации ЕАВ ?
Выяснилось, что нет ни одного "но".
Вариант 3 - это не EAV, конечно же. Это же очевидно.
LSVПожалуй невозможно сделать чистые вар.1 или вар. 2.
У обоих вариантов будут элементы др. друга. Только пропорции разные и трудоемкость реализации.
Пожалуйста, опишите один конкретный "смешанный вариант" (один из подвариантов варианта 2, раз EAV все равно используется). А по варианту 1 дождемся ответа автора этого варианта.
Уточняю:

Вариант 1. Классическая РМД с наследованием общих свойств (?) и отдельной таблицей на "специфические" свойства типа сущности. Здесь возникает вопрос о "масштабе специфичности". Свойство может принадлежать многим подтипам.
Вариант 2. С использованием EAV.
2.1. Разновидность 1. Требуется описание.
2.2. Разновидность 2. Требуется описание.
...
2.n. Разновидность n. Требуется описание.
Вариант 3. Классическая РМД с одной таблицей.
...
Рейтинг: 0 / 0
22.03.2013, 12:45
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194692
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Вариант 1. Классическая РМД с наследованием общих свойств (?) и отдельной таблицей на "специфические" свойства каждого подтипа типа сущности. Здесь возникает вопрос о "масштабе специфичности". Свойство может принадлежать многим подтипам. И любое из общих свойств (не важно всех или части подтипов) может перестать быть общим.
Вариант 2. С использованием EAV.
2.1. Разновидность 1. Требуется описание.
2.2. Разновидность 2. Требуется описание.
...
2.n. Разновидность n. Требуется описание.
Вариант 3. Классическая РМД с одной таблицей.
...
Рейтинг: 0 / 0
22.03.2013, 12:52
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194709
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Пожалуйста, опишите один конкретный "смешанный вариант" (один из подвариантов варианта 2, раз EAV все равно используется). А по варианту 1 дождемся ответа автора этого варианта.Вот смешанный:
1. Простые параметры хранятся в структуре а-ля ЕАВ (их могут добавлять простые пользователи).
2. Сложные параметры (со ссылками на многие справочники, с множеством спецификаций и сложной б/логикой) хранятся в своих отдельных таблицах.
Создаются такие параметры с помощью кучи DML и опытного программиста. Выборки, б/логика - тоже с помощью программиста.

Это будет самый общий случай. Но п.2 бывает не всегда (в смысле добавлять на лету). Тогда получим чистый вар.2.
...
Рейтинг: 0 / 0
22.03.2013, 13:00
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194721
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Комментарии к Варианту 1 показывают достаточно общую проблему технологии БД: стоит ли описывать отдельно свойства, а потом назначать их типам сущностей, для того, чтобы избегать "дублирующих описаний". Часто имеются какие-то отличия в некоторых атрибутах (чтобы не возникало путаницы, можно использовать другой термин) свойств , когда одно и то же свойство применяется к разным типам сущности.
...
Рейтинг: 0 / 0
22.03.2013, 13:04
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194730
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVПожалуйста, опишите один конкретный "смешанный вариант" (один из подвариантов варианта 2, раз EAV все равно используется). А по варианту 1 дождемся ответа автора этого варианта.Вот смешанный:
1. Простые параметры хранятся в структуре а-ля ЕАВ (их могут добавлять простые пользователи).
2. Сложные параметры (со ссылками на многие справочники, с множеством спецификаций и сложной б/логикой) хранятся в своих отдельных таблицах.
Создаются такие параметры с помощью кучи DML и опытного программиста. Выборки, б/логика - тоже с помощью программиста.

Это будет самый общий случай. Но п.2 бывает не всегда (в смысле добавлять на лету). Тогда получим чистый вар.2.
Пожалуйста, поясните суть термина "параметр".
Чтобы было понятнее, имеет ли отношение эта реализация к рассматриваемой задаче с одним типом сущности (Товар).
...
Рейтинг: 0 / 0
22.03.2013, 13:06
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194752
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVПожалуйста, опишите один конкретный "смешанный вариант" (один из подвариантов варианта 2, раз EAV все равно используется). А по варианту 1 дождемся ответа автора этого варианта.Вот смешанный:
1. Простые параметры хранятся в структуре а-ля ЕАВ (их могут добавлять простые пользователи).
2. Сложные параметры (со ссылками на многие справочники, с множеством спецификаций и сложной б/логикой) хранятся в своих отдельных таблицах.
Создаются такие параметры с помощью кучи DML и опытного программиста. Выборки, б/логика - тоже с помощью программиста.

Это будет самый общий случай. Но п.2 бывает не всегда (в смысле добавлять на лету). Тогда получим чистый вар.2.
Варианта 2 чистого нет! Поскольку все реализуют EAV по разному. Вы говорите, что если нет "сложных параметров", то остается только EAV . Но, какой именно вариант? Например, в drupal разные типы хранятся в отдельных таблицах. И это же тоже может влиять на производительность. Поэтому, опишите Ваш вариант. Пусть это будет 2.1.
...
Рейтинг: 0 / 0
22.03.2013, 13:12
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38194804
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
[quot LSV]1. Простые параметры хранятся в структуре а-ля ЕАВ (их могут добавлять простые пользователи).
2. Сложные параметры (со ссылками на многие справочники, с множеством спецификаций и сложной б/логикой) хранятся в своих отдельных таблицах.

И те и другие могут добавлять простые пользователи. И все это хозяйство в 2-х таблицах: объекты и свойства.
...
Рейтинг: 0 / 0
22.03.2013, 13:30
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195157
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
БредятинаВарианта 2 чистого нет! Поскольку все реализуют EAV по разному. Вы говорите, что если нет "сложных параметров", то остается только EAV . Но, какой именно вариант? Например, в drupal разные типы хранятся в отдельных таблицах. И это же тоже может влиять на производительность. Поэтому, опишите Ваш вариант. Пусть это будет 2.1.Чистого ничего нет. :)
В моей реализации одна таблица, в которой все типы (строка, целое,флоат, дата, булеан).
Можно разнести их по разным таблицам. В другом проекте, где я участвую, именно так. Не суть. Принцип тот же.
Производительность ? Трудно сказать. Возможно, где неск. таблиц будет немного быстрее.

Правильная суть ЕАВ(ИМХО) - для добавления нового параметра создаем новые строки в фиксированных таблицах.
Что такое параметр ? То, что изображено на картинке выше. Не суть как это назвать. Можно атрибутом. :)
...
Рейтинг: 0 / 0
22.03.2013, 16:32
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195319
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
LSV,

надо идти дальше - к механизму динамической типизации
ир познается через знания - тавтология типа такая
знания - не объекты, а признаки их классификации
те. важно иметь тезаурус -словарь свойств (объектов) уже отыменных
это как сито через который пропускается ноый объект
объекты с имеющие одинаковые совйства - типизируются по свойству ( тип = набор свойств)
объекты имеющие одинаковое значение одинаковых свойств - классифицируются (класс - все объекты всех типов с одинаковыми значенями типизированных свойств)
при этом свойства и их значения во времени меняются (ДОБАВЛЯЮТСЯ, УНИЧТОЖАЮТСЯ)
не типизированные (тем более не классифицированнные ) свойства объекта лежать в пуле - ждут часа обобщения
это механизм динамической классификации

вот тут все типизированные и тем более классифицированные вещи - это почти регулярны и их можно отобразить в отношения
а вот то что в пуле - в еав

молчать блин!!!
и пользоваться пока добрый
...
Рейтинг: 0 / 0
22.03.2013, 17:48
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195384
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
ViPRos,

Честно гря....неосилил сей поток сознания...
Хотя в целом согласен. :)
...
Рейтинг: 0 / 0
22.03.2013, 18:30
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195390
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
LSV,
счас пытаюсь этот поток всучить майкрософт
если получится отпишусь
...
Рейтинг: 0 / 0
22.03.2013, 18:37
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195406
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
ViPRos,

Цель не очень понятна. Вот установила Ваша система, что 2 обьекта в некоторый момент времени принадлежали к одному классу или типу, а потом перестали - и как этот вывод используется дальше?
Ваша типизация - она же по определению временная, а что можно сделать с типизацией, зависящей от времени - я как-то не очень представляю
...
Рейтинг: 0 / 0
22.03.2013, 18:50
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195410
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
Кот Матроскин,

с богами (те которые вневремени) не спорю
...
Рейтинг: 0 / 0
22.03.2013, 18:54
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195418
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
[quot _мод]LSVпропущено...

И те и другие могут добавлять простые пользователи. И все это хозяйство в 2-х таблицах: объекты и свойства.
Пожалуйста, приведите схемы всех используемых отношений РМД, иначе непонятно о чем речь, так как все используют разную терминологию. Возможно, у Вас, как и у LSV, Вариант 2.1. А возможно - другой.
Для Варианта 3 схема единственного отношения:
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
22.03.2013, 19:02
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195428
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVВ моей реализации одна таблица, в которой все типы (строка, целое,флоат, дата, булеан).
Можно разнести их по разным таблицам. В другом проекте, где я участвую, именно так. Не суть. Принцип тот же.
Производительность ? Трудно сказать. Возможно, где неск. таблиц будет немного быстрее.
Правильная суть ЕАВ(ИМХО) - для добавления нового параметра создаем новые строки в фиксированных таблицах.
Что такое параметр ? То, что изображено на картинке выше. Не суть как это назвать. Можно атрибутом. :)
Пожалуйста, приведите схемы всех используемых отношений РМД, иначе непонятно о чем речь, так как все используют разную терминологию. Возможно, у Вас тот же вариант, что и у _мод. А возможно - другой.
Понятно, что в "таблице значений" есть пять полей, и для каждой записи значение находится только в одном из них. Но не пользователь же вручную помещает значение в нужную колонку. Поэтому приведите схемы всех отношений. В Варианте 3 никаких проблем с типами нет - каждое поле имеет такой тип,который и нужен для данного свойства. Схема единственного отношения для Варианта 3:
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
22.03.2013, 19:08
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195433
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
ViPRosLSV,

надо идти дальше - к механизму динамической типизации
ир познается через знания - тавтология типа такая
знания - не объекты, а признаки их классификации
те. важно иметь тезаурус -словарь свойств (объектов) уже отыменных
это как сито через который пропускается ноый объект
объекты с имеющие одинаковые совйства - типизируются по свойству ( тип = набор свойств)
объекты имеющие одинаковое значение одинаковых свойств - классифицируются (класс - все объекты всех типов с одинаковыми значенями типизированных свойств)
при этом свойства и их значения во времени меняются (ДОБАВЛЯЮТСЯ, УНИЧТОЖАЮТСЯ)
не типизированные (тем более не классифицированнные ) свойства объекта лежать в пуле - ждут часа обобщения
это механизм динамической классификации

вот тут все типизированные и тем более классифицированные вещи - это почти регулярны и их можно отобразить в отношения
а вот то что в пуле - в еав

молчать блин!!!
и пользоваться пока добрый
Если Вы предлагаете один из вариантов Варианта 2, пожалуйста, приведите схемы всех используемых отношений РМД, иначе непонятно о чем речь, так как все используют разную терминологию. Возможно, у Вас тот же вариант, что и у _мод, и у LSV. А возможно - другой.
...
Рейтинг: 0 / 0
22.03.2013, 19:10
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195435
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
Бредятина,

уткнись, ты знаешь какой у меня вариант
...
Рейтинг: 0 / 0
22.03.2013, 19:11
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195439
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
ViPRosБредятина,
уткнись, ты знаешь какой у меня вариант
Это, к сожалению, не о модели верхнего уровня. А о модели нижнего уровня - вместо РМД. У Вас на нижнем уровне, судя по прошлым Вашим высказываниям, именно РМД. И здесь речь идет о конкретной задаче, а не о системе масштаба предприятия. Если у Вас настолько сложная конструкция из отношений РМД для реализации одного из подвариантов Варианта 2, то так и скажите. И зачем было писать что-то в этой теме, если она Вас не интересует???
...
Рейтинг: 0 / 0
22.03.2013, 19:16
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38195814
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
softwarerArhat109... давайте вместе ещё разок посмеемся ...
Да и не только вместе, присутствующие тоже поучаствуют...

Чё пропал, студент? Проверять-то (смеяться) будем или где? :) :) :)
...
Рейтинг: 0 / 0
23.03.2013, 11:40
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38197052
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Arhat109Чё пропал, студент? Проверять-то (смеяться) будем или где? :) :) :)
А, ты кстати о себе напомнил. Извини, не видел, что ты среди ночи чего-то накропал. Сейчас посмеёмся.
...
Рейтинг: 0 / 0
25.03.2013, 11:41
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38197076
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Arhat109Вы упустили один важный пункт, связанный с постановкой этой конкретной задачи, а именно: Что лучше (или - или). То есть суммарный объем информации - примерно константен.
Отчего же "упустил"? Просто выбрал более забавный способ тебя раскатать, когда ты начал вещать про "условия не заданы". Поскольку даже ежу понятно, что при "примерно константном" объёме данных вычислительная сложность подхода не играет вообще никакой роли, важна только скорость на этом объёме, но после этого как-то глупо тыкать в твою основную ошибку.

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

Arhat109Мои утверждения:
Ага, судя по многословию, на этот раз ты таки заметил, где сделал детскую ошибку, и пытаешься завалить её флудом. На всякий случай явно подсказываю: в оценке времени поиска "по одной таблице" O(log(N)) N - это количество записей. В оценке времени "по куче таблиц" O(N) N - это количество таблиц. Таким образом, пытаясь хотя как-то сравнивать одно с другим - смотри свою фразу "логарифм против линейного роста" - ты делаешь своё любимое "сравнивать тёплое с мягким".

Arhat109Итого, хотите разобраться, давайте.
1. Вариант:
Имеем (пусть для определенности) 1000 таблиц по 100 записей
То есть итого 100.000 записей. Сравниваем со сказанным ранее: объёмами, задекларированными топикстартером, а также моими словами про мой ноутбук. Итог: чувак пытается грубо передёрнуть даже там, где по декларациям, однозначно уверен в сокрушительной победе. Иди в морг, детка.
...
Рейтинг: 0 / 0
25.03.2013, 11:57
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38197219
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
softwarer,

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

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

В варианте трактовке второй части "от количества таблиц" - наши утверждения сходятся и "без чуть-чуть не так". Именно об этом и писал.

ну, так проверять будем? Если да, сегодня потрачу пару часов, на тестовый вариант для EAV. С тебя вариант по "1000 небольших таблиц".
...
Рейтинг: 0 / 0
25.03.2013, 13:08
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38197405
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Arhat109softwarer, то есть засчитать слив. Проверять не будем, так?
Мне в общем пофиг, что ты себе засчитаешь, ты сначала считать научись. По этой же причине проверять что-то с тобой, мягко говоря, неинтересно - это будет одно непрерывное тыканье в твои.. сомнительные предложения, назовём так. Впрочем, у тебя мелькнуло одно любопытное обещание - ты тут собирался за пару часов на чистом SQL реализовать приличный пространственный индекс для EAV. Хотелось бы посмотреть
...
Рейтинг: 0 / 0
25.03.2013, 15:20
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38197450
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
softwarer,

то есть слил. Ну так и нефиг было спорить про "теплое с мягким"... :)
...
Рейтинг: 0 / 0
25.03.2013, 15:46
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38197469
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Arhat109, ты имеешь полное право пытаться пыжиться сколько угодно. Повторишь ещё раз сто-двести - глядишь, и сам поверишь.
...
Рейтинг: 0 / 0
25.03.2013, 15:57
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38198138
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
softwarer,

:) пасибки.
...
Рейтинг: 0 / 0
26.03.2013, 07:13
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38198381
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
БредятинаПожалуйста, приведите схемы всех используемых отношений РМД, иначе непонятно о чем речь, так как все используют разную терминологию. Возможно, у Вас тот же вариант, что и у _мод. А возможно - другой.
Понятно, что в "таблице значений" есть пять полей, и для каждой записи значение находится только в одном из них. Но не пользователь же вручную помещает значение в нужную колонку. Поэтому приведите схемы всех отношений. В Варианте 3 никаких проблем с типами нет - каждое поле имеет такой тип,который и нужен для данного свойства. Схема единственного отношения для Варианта 3:
Товар {Свойство1, Свойство2, ..., СвойствоN}Какие схемы ? Какие отношения РМД ?

болдом: Есть единая процедура записи значений атрибутов. Она зачитывает тип атрибута (целое, флоат, строка и т.д.) и пишет в определенное поле (пишет ХП. Никакой SQL-динамики). Можно сначала проверить на допустимость значений и отформатировать введённое.
Не скажу, что это элегантное решение, но оно работает.
Таблица данных выглядит элементарно: ключи (ID атрибута, ID документа, вспомогательные поля) + поля данных всех нужных типов.
...
Рейтинг: 0 / 0
26.03.2013, 11:45
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38198540
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVБредятинаПожалуйста, приведите схемы всех используемых отношений РМД, иначе непонятно о чем речь, так как все используют разную терминологию. Возможно, у Вас тот же вариант, что и у _мод. А возможно - другой.
Понятно, что в "таблице значений" есть пять полей, и для каждой записи значение находится только в одном из них. Но не пользователь же вручную помещает значение в нужную колонку. Поэтому приведите схемы всех отношений. В Варианте 3 никаких проблем с типами нет - каждое поле имеет такой тип,который и нужен для данного свойства. Схема единственного отношения для Варианта 3:
Товар {Свойство1, Свойство2, ..., СвойствоN}Какие схемы ? Какие отношения РМД ?

болдом: Есть единая процедура записи значений атрибутов. Она зачитывает тип атрибута (целое, флоат, строка и т.д.) и пишет в определенное поле (пишет ХП. Никакой SQL-динамики). Можно сначала проверить на допустимость значений и отформатировать введённое.
Не скажу, что это элегантное решение, но оно работает.
Таблица данных выглядит элементарно: ключи (ID атрибута, ID документа, вспомогательные поля) + поля данных всех нужных типов.
Мне казалось. что я написал предельно ясный текст. Я же привел схемы всех отношений для Варианта 3 . В этом варианте одно отношение (таблица):
Товар {Свойство1, Свойство2, ..., СвойствоN}
Понятно, что в Вашем варианте (2.1) в "таблице значений" есть пять полей, и для каждой записи значение находится только в одном из них. Но не пользователь же вручную помещает значение в нужную колонку. Поэтому приведите схемы всех отношений (таблиц). В формате:
Отношение1{атрибут1отношения1, атрибут2отношения1, ...}
Отношение2{атрибут1отношения2, атрибут2отношения2, ...}
...
ОтношениеN{атрибут1отношенияN, атрибут2отношенияN, ...}
...
Рейтинг: 0 / 0
26.03.2013, 13:17
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38198551
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
БредятинаПоэтому приведите схемы всех отношений (таблиц). В формате:
Отношение1{атрибут1отношения1, атрибут2отношения1, ...}
Отношение2{атрибут1отношения2, атрибут2отношения2, ...}
...
ОтношениеN{атрибут1отношенияN, атрибут2отношенияN, ...}Пардон, а что это за формат или нотация ?
Оно нечитабельно, ИМХО.
Не буду я приводить никаких примеров. Свои мысли я изложил предельно подробно.
Нравится кому, или не нравится - мне пофиг.
...
Рейтинг: 0 / 0
26.03.2013, 13:24
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38198859
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSV,
Это я помню)) Непонятно только зачем было писать)) Что значит нравится или не нравится, если Вы засекретили основу любой БД - ее схему)) Жаль, что не получилось сделать нормальный анализ... Будем и дальше ждать бесконечных тем про EAV..
...
Рейтинг: 0 / 0
26.03.2013, 15:48
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38199100
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
БредятинаLSV,
Это я помню)) Непонятно только зачем было писать)) Что значит нравится или не нравится, если Вы засекретили основу любой БД - ее схему)) Жаль, что не получилось сделать нормальный анализ... Будем и дальше ждать бесконечных тем про EAV..Какие секреты ? Я рассказал подробностей реализации больше, чем любой мембер в этом топике. :)
Тут нечего прятать.
Табл 1. Справочник атрибутов(три важных поля) : Код, Название, Тип данного (целое/флоат/строка/дата/булеан).
Табл 2. Хранилище данных(упрощенно) : ID Документа, ID атрибута, целое, флоат, строка, дата, булеан.

Все действия (чтение, вставка, правка, удаление) только через ХП.

Какой еще анализ нужен ???
...
Рейтинг: 0 / 0
26.03.2013, 17:29
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38199115
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лагман
Участник
Закрепите уже тему EAV or not EAV
...
Рейтинг: 0 / 0
26.03.2013, 17:35
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38199308
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
LSVБредятинаLSV,
Это я помню)) Непонятно только зачем было писать)) Что значит нравится или не нравится, если Вы засекретили основу любой БД - ее схему)) Жаль, что не получилось сделать нормальный анализ... Будем и дальше ждать бесконечных тем про EAV..Какие секреты ? Я рассказал подробностей реализации больше, чем любой мембер в этом топике. :)
Тут нечего прятать.
Табл 1. Справочник атрибутов(три важных поля) : Код, Название, Тип данного (целое/флоат/строка/дата/булеан).
Табл 2. Хранилище данных(упрощенно) : ID Документа, ID атрибута, целое, флоат, строка, дата, булеан.

Все действия (чтение, вставка, правка, удаление) только через ХП.

Какой еще анализ нужен ???
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
26.03.2013, 19:29
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38421513
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Коллеги, реанимирую старую тему, но не флейма ради.
Не смог найти пост, в котором некто ЧАЛ, Андрей Леонидович или Бредятина декларирует внедрение ООБД на балабановской спичечной фабрике.
Последнее ее упоминание было тут.
...
Рейтинг: 0 / 0
09.10.2013, 13:44
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422021
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Infernal V. RavenКоллеги, реанимирую старую тему, но не флейма ради.
Не смог найти пост, в котором некто ЧАЛ, Андрей Леонидович или Бредятина декларирует внедрение ООБД на балабановской спичечной фабрике.
Последнее ее упоминание было тут.
Не стоило реанимировать, ради неправды)) Это постоянно декларирует vadiminfo. Я точно знаю, что на этой фабрике работает 1С. Может у нее и ООБД, но к теме это не имеет отношения на мой взгляд.
...
Рейтинг: 0 / 0
09.10.2013, 19:00
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422148
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаЯ точно знаю, что на этой фабрике работает 1С.

А куда же делась нашлепка на Кашу Информ Икс?

Ну той фирмы:


БредятинаЯ, Чернышев Андрей Леонидович.
Работаю в ЗАО Информ Икс.\


Где Вы работали. Она, эта нашлепка была еще ДОМД или КОМД, которую Вы тут типа толкали с мешочками


И в Сывтывкаре, где помнится Вы таки впарили эту нашлепку, тоже теперь 1С?

А ведь 1С это РМД.
...
Рейтинг: 0 / 0
09.10.2013, 22:08
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422399
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoБредятинаЯ точно знаю, что на этой фабрике работает 1С.

А куда же делась нашлепка на Кашу Информ Икс?

Ну той фирмы:


БредятинаЯ, Чернышев Андрей Леонидович.
Работаю в ЗАО Информ Икс.\


Где Вы работали. Она, эта нашлепка была еще ДОМД или КОМД, которую Вы тут типа толкали с мешочками


И в Сывтывкаре, где помнится Вы таки впарили эту нашлепку, тоже теперь 1С?

А ведь 1С это РМД.
А еще я учился в 317-ой средней школе)) На Вашей любимой фабрике 1С стоит по моей рекомендации)) Даже исследования проводили для выбора. Потому что им не нужна система масштаба предприятия, а нужен именно бухгалтерский учет. Там, где заинтересованы в корпоративной системе, там используют именно СУБД, а не СХОД)) И, как правило, используют в качестве MUMPS вовсе не Cache. И не нужно давать своих оценок про МД - выглядит совсем уж нелепо. В 1С не РМД, и даже не такая архитектура, которую мы рассматривали здесь:
13577413
Вероятно, у Вас не получилось впарить СХОД Oracle на эту Вашу фабрику, и Вы теперь не можете успокоиться? И опять вступаете в диалог с банальным идиотом))
...
Рейтинг: 0 / 0
10.10.2013, 09:43
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422408
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoБредятинаЯ точно знаю, что на этой фабрике работает 1С.

А куда же делась нашлепка на Кашу Информ Икс?

Ну той фирмы:


БредятинаЯ, Чернышев Андрей Леонидович.
Работаю в ЗАО Информ Икс.\


Где Вы работали. Она, эта нашлепка была еще ДОМД или КОМД, которую Вы тут типа толкали с мешочками


И в Сывтывкаре, где помнится Вы таки впарили эту нашлепку, тоже теперь 1С?

А ведь 1С это РМД.
А теперь по существу:
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
10.10.2013, 09:51
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422429
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
БредятинаvadiminfoА ведь 1С это РМД.
... И не нужно давать своих оценок про МД - выглядит совсем уж нелепо. В 1С не РМД, и даже не такая архитектура, которую мы рассматривали здесь:
13577413

Для общего представления хотя бы
http://v8.1c.ru/overview/Term_000000641.htm
...
Рейтинг: 0 / 0
10.10.2013, 10:05
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422612
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаА еще я учился в 317-ой средней школе))
Оно и видно, что образование средние, иначе бы институт привели.


БредятинаНа Вашей любимой фабрике 1С стоит по моей рекомендации))

К инфом икс отношения не имели? Не пропогандировали оное как ДОМД или КОМД?
В ЗАО Информ Икс не работали? Или оное 1С толкало, а не инфом икс?

Бредятинамы рассматривали здесь:
13577413


Вот именно что вы рассматривали, а не Чен, Дейт и т.п.

Бредятина

Вероятно, у Вас не получилось впарить СХОД Oracle на эту Вашу фабрику

О фабирке я узнал в связи с тем, что они сподобились поставить нашлепку информ икс. А про оную исключительно благодаря Вашим усилиям.
Что до СУБД Оракле то оная занимает под 30% рынка, стоит в крупнейших банках.

И в том числе ее юзает 1С:
БредятинаДля общего представления хотя бы


Общего представления Вам не достаточно, Вы никогда не отличали уровень БД от остальных частей ИС.
Но все равно:
Бредятина http://v8.1c.ru/overview/Term_000000662.htm


Там про СУБД а не про то, что в Вашей ссылке другие не БДшные уровни:

"Основное отличие заключается в том, что разработчик 1С:Предприятия не обращается к базе данных напрямую".
...
Рейтинг: 0 / 0
10.10.2013, 11:20
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422660
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoБредятинаА еще я учился в 317-ой средней школе))
Оно и видно, что образование средние, иначе бы институт привели.
Разумеется. Впрочем, и среднее-то так себе, как и положено идиоту))
vadiminfoБредятинаНа Вашей любимой фабрике 1С стоит по моей рекомендации))

К инфом икс отношения не имели? Не пропогандировали оное как ДОМД или КОМД?
В ЗАО Информ Икс не работали? Или оное 1С толкало, а не инфом икс?
Лжете, как всегда)) Вот мой текст:
На Вашей любимой фабрике 1С стоит по моей рекомендации)) Даже исследования проводили для выбора. Потому что им не нужна система масштаба предприятия, а нужен именно бухгалтерский учет. Там, где заинтересованы в корпоративной системе, там используют именно СУБД, а не СХОД)) И, как правило, используют в качестве MUMPS вовсе не Cache.
vadiminfoБредятинамы рассматривали здесь:
13577413

Вот именно что вы рассматривали, а не Чен, Дейт и т.п.
Лжете. Мы рассматривали. Вы принимали в этом активное участие, и многое поняли. А то, что Дейт чего-то не понимает, так это его проблемы, а не мои))
vadiminfoБредятинаВероятно, у Вас не получилось впарить СХОД Oracle на эту Вашу фабрику

О фабирке я узнал в связи с тем, что они сподобились поставить нашлепку информ икс. А про оную исключительно благодаря Вашим усилиям.
Что до СУБД Оракле то оная занимает под 30% рынка, стоит в крупнейших банках.
И в том числе ее юзает 1С:
Хорошо, что подтвердили, что Вам не удалось впарить Oracle на фабрике, чтобы ее "юзала 1с"))) Было бы совсем честно пояснить почему именно не удалось, раз уж по теме Вам все равно нечего сказать))
vadiminfoБредятинаДля общего представления хотя бы

Общего представления Вам не достаточно, Вы никогда не отличали уровень БД от остальных частей ИС.
Но все равно:
Бредятина http://v8.1c.ru/overview/Term_000000662.htm

Там про СУБД а не про то, что в Вашей ссылке другие не БДшные уровни:
"Основное отличие заключается в том, что разработчик 1С:Предприятия не обращается к базе данных напрямую".
Ложь. Я Вам дал учебную ссылку, из которой понятно, что в 1с не только не РМД, но даже и не архитектура, которую мы рассматривали здесь:
13577413
Либо говорите по существу, либо ничего не говорите)) Вроде бы логично?))
...
Рейтинг: 0 / 0
10.10.2013, 11:40
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422664
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Напомню на чем мы остановились.
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
10.10.2013, 11:42
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422689
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаЛжете, как всегда)) Вот мой текст:


А это чей текст:

БредятинаЯ, Чернышев Андрей Леонидович.
Работаю в ЗАО Информ Икс.


БредятинаЛжете. Мы рассматривали. Вы принимали в этом активное участие, и многое поняли.

Вы рассматривали, знамо дело: Вы любитель ахиней.
Я для понимания предпочитаю более продвинутые источники: Конноли, Дейт. Поржать над Вашими мыстлями, это да, я рассматриваю.

БредятинаА то, что Дейт чего-то не понимает, так это его проблемы, а не мои))

С Вашим уровнем осталось только о проблемах Дйта думать.

БредятинаЛожь. Я Вам дал учебную ссылку, из которой понятно, что в 1с не только не РМД, но даже и не архитектура, которую мы рассматривали здесь:
13577413


Ну архитектуры которые где бы Вы не рассаматривали, могут быть только в нашлепках типа информ икс.

То что Вы привели про 1С не уровни БД. Но у ея есть и БД. А для оной юзаются СУБД, что я дал ссылку. Оные относят к РСУБД, но или ОРУБД - расширения РМД.
Впрочем, что Вам объяснять? Как Вам ни расжевывай, до Вас никада ничего не доходит.
...
Рейтинг: 0 / 0
10.10.2013, 12:00
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422723
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoБредятинаЛжете, как всегда)) Вот мой текст:


А это чей текст:

БредятинаЯ, Чернышев Андрей Леонидович.
Работаю в ЗАО Информ Икс.

Лжете, как всегда)) Вот мой текст, которым я исчерпывающе ответил на конкретный вопрос, и который Вы не верно процитировали:
На Вашей любимой фабрике 1С стоит по моей рекомендации)) Даже исследования проводили для выбора. Потому что им не нужна система масштаба предприятия, а нужен именно бухгалтерский учет. Там, где заинтересованы в корпоративной системе, там используют именно СУБД, а не СХОД)) И, как правило, используют в качестве MUMPS вовсе не Cache.
---
Разумеется, работал. Я же написал. Не стоит Вам лгать и заниматься подлогом постоянно))
vadiminfoБредятинаЛжете. Мы рассматривали. Вы принимали в этом активное участие, и многое поняли.

Вы рассматривали, знамо дело: Вы любитель ахиней.
Я для понимания предпочитаю более продвинутые источники: Конноли, Дейт. Поржать над Вашими мыстлями, это да, я рассматриваю.
Лжете. Мы рассматривали. Вы принимали в этом активное участие, и многое поняли.
vadiminfoБредятинаА то, что Дейт чего-то не понимает, так это его проблемы, а не мои))

С Вашим уровнем осталось только о проблемах Дйта думать.
Глупость. Я о них не думаю. Это Вам нужно о них думать, потому что у Вас они те же. Просто Вам больше повезло - есть возможность узнать от меня о БД много полезного))
vadiminfoБредятинаЛожь. Я Вам дал учебную ссылку, из которой понятно, что в 1с не только не РМД, но даже и не архитектура, которую мы рассматривали здесь:
13577413

Ну архитектуры которые где бы Вы не рассаматривали, могут быть только в нашлепках типа информ икс.
Ложь. Вы сказали глупость о МД 1С. И теперь лжете и занимаетесь прямым подлогом (даже ссылку подменили), вместо того, чтобы признать очевидную вещь:
что в 1с не только не РМД, но даже и не архитектура, которую мы рассматривали здесь:
13577413
vadiminfoТо что Вы привели про 1С не уровни БД. Но у ея есть и БД. А для оной юзаются СУБД, что я дал ссылку. Оные относят к РСУБД, но или ОРУБД - расширения РМД.
Впрочем, что Вам объяснять? Как Вам ни расжевывай, до Вас никада ничего не доходит.
Ложь. Наглая. Вы сказали глупость о МД 1С. И теперь лжете и занимаетесь прямым подлогом (даже ссылку подменили), вместо того, чтобы признать очевидную вещь:
что в 1с не только не РМД, но даже и не архитектура, которую мы рассматривали здесь:
13577413
...
Рейтинг: 0 / 0
10.10.2013, 12:21
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422729
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Напомню на чем мы остановились по существу вопроса.
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
10.10.2013, 12:22
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422750
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаЛожь. Наглая. ...
Не. Правда. Просто она до Вас недоходит:

БредятинаДо таких идиотов, как я, конечно, не доходит))
...
Рейтинг: 0 / 0
10.10.2013, 12:27
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422758
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> реанимирую старую тему

Infernal V. Raven, вам оно действительно было нужно? Теперь этот фонтан дерьма заткнуть будет очень сложно.
...
Рейтинг: 0 / 0
10.10.2013, 12:31
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422770
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
guest_20040621> реанимирую старую тему

Infernal V. Raven, вам оно действительно было нужно? Теперь этот фонтан дерьма заткнуть будет очень сложно.
Ваш фонтан дерьма, действительно, очень сложно заткнуть)) Редко, когда Вам удается высказать точную мысль))
...
Рейтинг: 0 / 0
10.10.2013, 12:37
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422771
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoБредятинаЛожь. Наглая. ...
Не. Правда. Просто она до Вас недоходит:

БредятинаДо таких идиотов, как я, конечно, не доходит))

Ага)) Значит дошло про МД)) Молодец!
...
Рейтинг: 0 / 0
10.10.2013, 12:38
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422778
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
guest_20040621> реанимирую старую тему

Infernal V. Raven, вам оно действительно было нужно? Теперь этот фонтан дерьма заткнуть будет очень сложно.
Напомню на чем мы остановились по существу вопроса.
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
10.10.2013, 12:41
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422792
Опрос
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Опрос
Гость
Есть хоть кто-то на форуме, кого этот бредятина не за.б.л ?
...
Рейтинг: 0 / 0
10.10.2013, 12:46
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422801
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
ОпросЕсть хоть кто-то на форуме, кого этот бредятина не за.б.л ?
Неточная формулировка))
Напомню на чем мы остановились по существу вопроса.
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
10.10.2013, 12:47
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422820
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
ОпросЕсть хоть кто-то на форуме, кого этот бредятина не за.б.л ?
все норм, он открыл Истину и Зациклился
А Истина в том, что мир сложен :)
...
Рейтинг: 0 / 0
10.10.2013, 12:58
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422839
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
guest_20040621> реанимирую старую тему
Infernal V. Raven, вам оно действительно было нужно? Теперь этот фонтан дерьма заткнуть будет очень сложно.
Честно говоря я не ожидал, что участники примутся продолжать как ни в чем не бывало после полугодичного перерыва.

Поиск в гугле по ЗАО Информ Икс выдает первые ссылки на сайт росправосудие . Символично?
...
Рейтинг: 0 / 0
10.10.2013, 13:08
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422840
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
ViPRosОпросЕсть хоть кто-то на форуме, кого этот бредятина не за.б.л ?
все норм, он открыл Истину и Зациклился
А Истина в том, что мир сложен :)
Конечно, сложен. Но я иду последовательно, и никогда не зацикливаюсь))
Напомню на чем мы остановились по существу вопроса.
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
10.10.2013, 13:08
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38422848
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
vadiminfoЧто до СУБД Оракле то оная занимает под 30% рынка, стоит в крупнейших банках.
И в том числе ее юзает 1С

Честно говоря 1с в продакшн на Оракл я не встречал. Связано это в первую очередь с тем, что код на языке 1с не избавляет от потребности знания СУБД (если производительность нужна вменяемая или объемы данных большие). Традиционные подходы программистов 1с ориентируются больше на MSSQL.
...
Рейтинг: 0 / 0
10.10.2013, 13:13
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38423091
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Infernal V. Ravenguest_20040621> реанимирую старую тему
Infernal V. Raven, вам оно действительно было нужно? Теперь этот фонтан дерьма заткнуть будет очень сложно.
Честно говоря я не ожидал, что участники примутся продолжать как ни в чем не бывало после полугодичного перерыва.

Поиск в гугле по ЗАО Информ Икс выдает первые ссылки на сайт росправосудие . Символично?
Непоследовательно - от спичечной фабрики vadimifo к росправосудию))
Напомню на чем мы остановились по существу вопроса.
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}
...
Рейтинг: 0 / 0
10.10.2013, 15:26
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38423319
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Символично?

Более, чем. В яблочко.
...
Рейтинг: 0 / 0
10.10.2013, 17:03
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38423322
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
guest_20040621> Символично?

Более, чем. В яблочко.
То есть, Вы оба за вариант 2.1:

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}
Я так и предполагал)))
...
Рейтинг: 0 / 0
10.10.2013, 17:08
| Ответить | Цитировать | Написать  
195 сообщений из 195, показаны все 8 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД с созданием кучи таблиц
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1541100]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 153ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 164ms
get tp. blocked users:
 2ms
others: 233ms
total:  594ms
созд. / загр.: 594ms
x
x
Закрыть


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