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

КурдльОчень не правильно в архитектурном плане раскидывать документы в отдельные таблицы в разрезе их типов.
-1

КурдльОчень правильно создавать модель данных наиболее приближенной к предметной области.
Очень правильно понимать принципы хранения информации и принципы построения оптимальных запросов.

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

КурдльРазные документы могут иметь разные связи и условия проверок!
Корневое слово - документы. Документ - это сущность, неделимая. Даже в разрезе типов.
Предположим, имеется 100 млн. документов и 100 типов.
А теперь пошевелите мозгами и прикиньте, какой будет план при отборе документов 10-и типов?
10 джойнов:


Самая засада будет в индексном скане, хотя стоимость Index Seek будет ещё выше.
Нам придётся обращаться к 10 таблицам-миллионникам за дополнительными атрибутами.
Именно в этом и есть засада.
Проблема в том, милый Курдлёк, что Вы не участвовали в разрабатотке высоконагруженных систем. Имея бы опыт участии в подобных проектах Вы бы так не говорили:

КурдльС производительностью пусть железячники геморроятся.

... ибо такие "программисты" нах никому не нужны.

P.S. Проекты типа хеллоу-ворлд - вот она Ваша ниша :)

КурдльНикакие сложности разработки и расширяемости не могут оправдать разрушение логики модели.
См. выше про хеллоу-ворлдщиков

P.S. Когда Ваш программный комплекс встанет раком (+ туда же интеграцию со сторонними системами - всякие ссис и бизтолки, + туда же резервое копирование, + туда же репликацию данных), тогда Вы лично пойдёте к директору и расскажете про разрушение логики модели
P.S2. Кстати, да будет Вам известно - логика модели при этом не разрушается, ибо мы работаем с единой сущностью документ. Он не должен быть делим в разрезе его типа. barser уже вещал про Фаулеровские наставления. Если Вы, Курдль, считаете себя умнее и опытнее Великого Фаулера, то я умолкаю :)

КурдльИначе вместо того, чтобы защищать ваш проект от тяжелейших ошибок уровня бизнес-логики, БД будет лишь придатком воспаленного воображения разработчиков прикладных модулей.
Шум травы. А ружье за цевьё не держалось ) С возрастом проходит )

barserБольшое спасибо за ценное замечание. Фаулер, насколько помню, в "Архитектуре корпоративного ПО" давал схожую рекомендацию. Правда, сложности с установкой constraints not null на уровне БД появляются, а также люди, которые будут работать с базой на уровне MS access могут не понять фишки (ну, тут наверное дополнительные вьюхи смогут помочь)...
Ну, это уже десятое. Можете переложить логику not null на клиента, можете вьюшки, можете еще как - это уже как требуется.

barserНа данном этапе разработки изменить способ хранения вполне реально, имхо...
Вынесу это на обсуждение между участниками проекта на след. неделе. Еще раз спасибо!
Да, обсудите, дело-то серьезное.

barserА может быть есть какое-то общее правило для выбора типа наследования? Когда что лучше подходит?
Вот на уровне классов - играйте как хотите, но схема в БД должна быть нераздробленной. Это ж Вам не мастер детэил )

barserКурдльНу вот, мнения разделились... :) Как же найти разумный компромисс?
Меня, честно говоря, несколько смущает обилие join'ов в запросах к сущностям, у которых имеется много наследников... Никак не могу об этом не думать)
barser, какие мнения могут быть у Курдля, нашего адошного хеллоуворлдщика?

barserЕсли Вас не слишком затруднит, не могли бы Вы хотя бы вкратце перечислить конкретные проблемы, возникновение которых заставило сожалеть о принятом архитектурном решении?
1. Тормоза на выборках с большим кол-вом типов документов
2. Периодические блокировки (для наборов под сводные ведомости и прочие отчеты - курилось грязное чтение, но программный комплекс не ограничивался отчетами, разумеется). И как следствие - доп. нагрузка на администрирование БД
3. Мерж-репликация. Танцы с бубном: иногда случалось так, что "типы" раньше приходили на паблишер, чем "шапки" документов. Щас уже не припомню, в чём именно там была засада.
4. Более сложная интеграция со сторонними системами.

КурдльАрхитекторы оракла заявляют, что скорость доступа к двум полям "соединенных" таблиц такая же, как к двум полям одной таблицы.
Курдль, ну во-первых - это бред. Во-вторых, Вы же знаете правила хорошего тона на sql.ru - всегда заявления подобного рода хорошо было бы подкреплять ссылками на источник.

КурдльВопросы производительности всегда будут возникать. Но это не значит, что ей в угоду мы должны впихивать невпихуемое "в одну таблицу".
"Всё в одну таблицу" == "Документы в одной таблице"
Чуете разницу? Так что выражайтесь яснее и не накручивайте слов не по делу.

КурдльПроизводители СУБД и АС позаботятся о том, чтобы все возрастающие объемы информации не приводили к замедлению и остановке процессов обработки данных.
Производители СУБД бессильны перед ламерами, которые не знают, не умеют, не понимают. Это факт.

КурдльТак, например, один из известнейших производителей СУБД создал систему с постолбцового хранения данных, взамен построчного. Теперь его СУБД работают с объемами в 50ТБ и не кашляют. А у Вас какие объемы?
Так например, один человек обрёл крылья и полетел. А у Вас какие крылья?
P.S. Как всегда - ниачём. Нт названий, ни ссылок, ни фактов. Просто шелест травы, не более того.

barserКурдльЕще бы ссылку на это заявление архитекторов оракла, если Вас не затруднит.
Во-во

КурдльА у Вас какие объемы?

barserИ сильно сомневаюсь, что в ближайшие года 2-3 объем основной схемы превысит 50-100 Гб.
Ну, я бы не сказал, что это-таки мало :)

Курдль, всплески эмоций оставьте у себя в чемодане, Вы, лучше по делу отвечайте :)

Итак, прошу ссылку на вот это заявление:

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

... и расскажите поподробней про "известнейшую" столбцовую БД:

КурдльТак, например, один из известнейших производителей СУБД создал систему с постолбцового хранения данных, взамен построчного. Теперь его СУБД работают с объемами в 50ТБ и не кашляют.

P.S. А то как-то не хорошо получается, - заднюю включить не дам! )

Курдль1. Ради простого поддержания спора не готов тратить свое время на поиски цитат. Но это заявление звучало раньше почти на всех конференциях от оракла. Сходите в форум ораклистов на этом сайте - может они точно наведут (у Вас же "безлимитка":).
Курдль, так дела не делаются. Если не найдете подтверждения сего безумного факта - будет расценено как слив. Постарайтесь отвечать за свои слова, а не бросать их на ветер.
Всё еще жду ссылки.

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

КурдльP.S. Не пытайтесь втянуть меня в досужий треп "у кого длиннее и толще"
Я не пытаюсь никого никуда втягивать. Я лишь хочу, чтобы Вы отвечали за свои слова.

КурдльВедь победивший в таком споре ЗДЕСЬ может иметь длиннее и толще всего-навсего... язык (или пальцы).
Какой спор, Курдль? С кем? Программист, заявляющий такое:

КурдльС производительностью пусть железячники геморроятся

заранее обречён на погибель.

P.S. Остальной оффтоп поскипан

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

КурдльНапример, когда пусть даже на рекламном семинаре от Sybase, выходит на сцену начдепа IT налоговой службы США и говорит, что благодаря указанной СУХД за 5 лет ими получена доп. прибыль в $60 млн. и что нынешний объем ХД - 150ТБ, при этом оборудование - отнюдь не "супердома", я не вижу причин ему не верить.
Вы хотели чего-то другого ожидать на рекламном семинаре от Sybase?

P.S. И, вообще, тема не о Sybase и не о постолбцовом хранении. Забудьте.

КурдльА я из своего болота могу квакнуть в оправдвние сентенции об "одной сессии и одновременного доступа" то, что СУХД не специализируются на OLTP системах, а лишь на OLAP, где, как правило, запись ведется по ночам, а в рабочее время - лишь упорная аналитическая выборка.
Я, вообще, не понимаю, зачем Вы начали квакать в эту сторону. Оффтоп?

P.S. Линк будет?

КурдльНет, конечно! Я же сказал, что не буду тратить свое время на подобные поиски.
То есть, Вы считаете хорошим тоном - ляпнуть и уйти в сторону без аргументов?

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

КурдльИ от слов, что производительностью АС должны заниматься специально обученные люди, никак не способные повлиять на структуру данных, я не откажусь.
Я чувствую некий спад амбиций. Тут:
КурдльС производительностью пусть железячники геморроятся
... было поамбициозней и пожарче заявлено )
P.S. Вы до сих пор не понимаете, что программист способен написать такой кривой код, который и оптимизировать смысла не имеет?
P.S2. Во-вторых, если Вы так акцентируете внимание на разделение ролей - то я бы Вас к разработке схемы БД не подпустил бы. Как Вы говорите, пусть этим DBD занимается.