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

КурдльОчень не правильно в архитектурном плане раскидывать документы в отдельные таблицы в разрезе их типов.
-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 занимается.

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

P.S. "Приверженцем хибера" не являюсь. Это просто очень хорошая ORM со своими плюсами и минусами.

4umgУважаемый МСУ, ответьте плиз на парочку вопросов:
Ну вот, просили парочу, а родили целых шесть (пять)!

4umg1. Как и где Вам удалось хранить в одной таблице, разные по содержанию и набору атрибутов документы/сущности - платежные поручения, контракты, выписки со счетов, служебные записки, протоколы заседаний и т.д. ?!
Во-первых, не нужно таких опрометчивых замечаний по поводу того, что хранение было организовано разными по содержанию и набору атрибутов документов. Ибо документ иного типа имел массу общего с "предком" (номер, различные даты операций). Просто в различных вариациях определенные атрибуты не заполнялись. Но, тем не менее, этот факт не мешал сущности был сущностью :)
Во-вторых, бизнес был учетно-транспортный, сбыт. Как-то накладные, счета, счета-фактуры, товарно-транспортные документы и иже.
В-третьих, иные документы (как то контракты), не имеющие никакого отношения к кактегории сбыта, хостились в своей отдельной таблице.
То есть, иными словами, разнородность документов объединяла некая абстрактная кактегория. Принятие решения под введение новой категории (то есть создание новой таблицы) осуществлялось после исследования, которое показывало, - может ли таблица захостить схожие документы.

4umg2. Как Вы строили уникальный ключ (UK) по такой МЕГА таблице, ведь уникальность для каждого типа документа в системе определяется своим набором атрибутов (выписка со счета ежегодно, номер контракта с рабочего места с контрагентом не должен задублироваться?!).
Вы забыли, что еще и номер счета-фактуры должен быть уникальным в разрезе года, а так же быть последовательным и непрерывным ))
Во-первых, таблица была не "мега", выше я изложил про идею категорий.
Во-вторых, уникальностью документов свободно может отруливать триггер. Клиенту не нужно этой логики.
В-третьих, (вопросы типизации) можно возложить работу (частный случай) триггера на SQLCLR по форуме: сервер выбирает - функция SQLCLR обрабатывает и выдает результат.
В-четвертых, Вы не сказали - Вы пишете расширяемую СЭД (вида 1С, Documentum, OpenText И иже) или под нужды предприятия? Это очень важно, ибо расширяемость не бесплатна - мы всегда жертвуем произодительностью.

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

4umg3. Как Вы создавали внешний ключик (FK) в связанных таблицах .. таблице проводок например на данную таблицу на уровне СУБД, а то на основании СЗ изменения паспортных данных спишутся средства с лицевого счета вкладчика?!
Ну, думаю, уже смысла нет давать комментарии по этому вопросу.

4umg5. Join-ы по внешним ключам при наличии индексов и грамотной настройке сервера выполняются за миллисекунды, мы же не собираемся заниматься тут аналитикой, да и у Oracle кстати неплохой набор аналитических функций. Причем тут блокировки, интеграция, репликация ... ?!!!
1. Разумеется, наличие индексов обязательно.
2. Что понимается под грамотной настройкой сервера? Конкретизируйте.
3. За миллисекунды выполняется запрос на пару джойнов при наборе в сотню строк. При ста джойнах и при объемах таблиц > 10 (про сотни молчу) млн. записей Вы будете петь уже другие песни.
4. Как это блокировки не причём? Уважаемый, читайте про конкурентный доступ, уровни изоляции и иже. Ну даёте, пипец... :) Особенно, когда сервер выбирает на основе плана выполнения запроса - сканирование индекса. А если у Вас еще и индексы, то не забываем, что если есть в таблице кластерный индекс, все некластерные индексы будут содержать столбцы самого индекса и столбцы кластерного индекса. Действительно, причём тут блокировки
5. Репликация и блокировки. Ну да, разумеется, при реплике блокировок быть не может по определению :)
6. Ладно, проехали )) Учите матчасть.

4umg6. Вопрос в другом, а зачем связывать 10, 20 ... таблиц документов в один запрос?! Какому нужны в одном запросе данные платежей, контрактов, выписок и т.д. ?! Зачем нужны эти миллионы связанных документов?! ))
В основном для интеграции со сторонними системами. Экспорту данных за период могут понадобиться разнотипные документы.

4umgМожет стоит выделить необходимые атрибуты и ссылки в классе Document?! (Id, наименование документа, дата документа, штрих-код, путь к файлу ... и т.д.)
Не получится, уже объяснял почему. Если у Вас пара типов - ваяйте.

4umgМСУ, о чем жалели то, на чем тормозил сервак и застрял проект?! ))
Основное, - блокировки.
P.S. Проект на застрял, его потом подняли )

4umg1.Ну так, если вы вводите новую категорию .. значит наследуетесь от документа?!
Нет и еще раз нет. Вы так и не поняли, - единого понятия "документ" нет и не должно быть.
Перечитайте еще раз то, о чём я писал... :(

4umgНа сегодня я бы выделил несколько важных для нас категорий документов:
договора/контракты - это основной учет.

документы, по которым проводятся начисления/cписания денежных средств и их перераспределение - платежные поручения, бухгалтерские справки, протоколы и распорядительные письма вкладчиков.

служебные (внутренние документы) - служебные записки и ответы на них (их кстати может автоматом генерить система по определенному событию) на изменение учетных данных

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

Отлично! Итого под данные категории создайте 4 таблицы, которые будут принимать документы конкретной категории. Всё.

4umg2. Да мы пишем СЭД под нужды конкретной организаци и совершенствуем уже существующую, которая проработала лет 15 и порядком устарела )). Да, она интегрирована с 1С и Мотивом, правда в одностороннем порядке - из мотива документы попадают в нашу систему.
Ох как это знакомо :) Главное - не нагадить и не облажаться в самом начале - этапе проектирования схемы. Так что все ооповские заморочки отложите пока на задний план (я про разделения, думаю, этот момент можно закрыть уже, всем всё понятно) - делайте схему. И такую схему, чтобы акцентировать, прежде всего, внимание на быстродействие .

4umg3. По поводу производительности сервера Oracle ... я имел ввиду кешировние запросов, секционирование и пр.
Ну так кеширование есть не только в оракле, нашли чем удивить :) Более того, есть возможность перекомпиляции планов ("рекешинг").
Вот тут есть интересная статейка на тему: Кэширование и повторное использование плана выполнения
(правда под сиквел). Ну да ладно, это оффтоп.

4umgВы издеваетесь про пару джойнов на сотню строк??! )))
Вы различаете понятия издёвки и утрирования? По-ходу дела нет

4umgВы хоть сами-то писали запросы или хранимики со 100 джойнами или все хибером ??!)).
См. выше про утрирование. Я хотел донести идею, что с ростом количества новых типов Вы будет получать в бубен новый дополнительный джойн, что не может не сказываться на производительности выполнения запроса. Очень жаль, что приходится разжевывать этот момент.
Банально, Ваш сотрудник барсер это понял с первого раза...

4umgПо поводу таблиц миллионников (прям система бюрократ ))), думую на днях промоделируем на тестовых данных и посмотрим план ...
Вот с этого и нужно было начинать, а не вещать тут про миллисекундность выполнения батчей :)

4umgна сегодняшний таблица движения средства (4 млн) легко связывается со ста тысячниками документами, счетами, контрагентами, адресами и пр ... 500 записей не более чем за 100ms .. и то, если выбирать все поля таблиц
Мда, батенька. Да Вы еще и фантаст песатель
P.S. Про нагрузочное тестирование рассказывать? Когда в Вашу систему будут ломиться 10к юзеров, интеграционных коннектов, резервных копирований, и иже с ними.

4umg4. Что-то я не в курю, уважаемый .. вы про какие блокировки и уровни изоляции в ORACLE на обычный SELECT c джойнами?! Или я что-то не догоняю?! Вы под какую СУБД систему писали?!
Уважаемый, чтобы понимать, про какие блокировки я говорю, нужно понимать, что Вашу систему будут курить не только парочка бабушек со студентом-администратором :) Мысль ясна или расшифровать?

4umg5. Хмм, экспорт данных разовая служебная операция, которая может выполняться по расписанию, в ночное время, за определенный период, на отдельным серваке и не обязательно через хибер.
Как Вы недальнозорки... Дорогой 4umg, а Вы не задумывались над тем, что "ночного времени" Вам может не хватить? :)
Не нужно мыслить на уровнем full backup, это могут даже студенты начальных курсов. Есть еще такое понятие, как differential backup (full differential backup), а так же резервное копирование журналов транзакций. Например, можно производить полное резервное копирование по понедельникам, а в каждый другой день недели — резервное копирование журналов транзакций. В результате во вторник в резервную копию будут записаны те изменения, которые произошли с понедельника по вторник, в среду будут записаны изменения со вторника по среду и т. п. Такое резервное копирование будет выполняться быстрее, чем разностное, но придется пожертвовать скоростью восстановления. Если сбой произойдет, например, в четверг, то при использовании разностного резервного копирования вам потребуются две резервные копии: за понедельник (полная) и за четверг (разностная). В той же ситуации при использовании резервного копирования только журналов транзакций вам потребуются: полная копия за понедельник и копии журналов транзакций за вторник, среду и четверг.

4umgЭто не аргумент, который влияет на на работу СЭД
Это аргумент, который влияет на на работу СЭД, учитае матчасть и читайте про разностное копирование. Да и, вообще, закрепить знания по типам резервного копирования Вам не помешает.

P.S. Удачи.

КурдльВот где ключевая концептуальная ошибка!
Это не ошибка, это правильное направление.

КурдльДа поймите же Вы, что для некоторых предметных областей пытаться пойти на компромисс с логикой ради быстродействия - смерти подобно!
Вы этого не понимаете, так как не работали с высоконагруженными системами.

КурдльЯ еще раз повторюсь, что модель данных может послужить отличным защитником от логических ошибок последующих этапов, если она правильно спроектирована.
Логических ошибок нет и не было. Где тут логические ошибки?

КурдльИ я не понял сентенцию о 4-х таблицах документов.
Курдль, для Вас персонально не хочу разжевывать... Писал доходчиво, очень доходчиво. Учитесь читать, что-ли.

КурдльВы имеете в виду, что они не должны иметь суперкласс?
Не должны.

КурдльТак это и повлечет за собой кучу ненужных джоинов при необходимости собрать их в едином списке или при общей обработке.
Единый список невозможен ибо это разнородные понятия. Единый список может быть построен только в разрезе документов одной категории. Иначе, получается, что Вы хотите построить список баранов с арбузами. Что общего у барана с арбузов?

КурдльПример с документами не самый яркий. Есть куда более запущенные случаи, напр. финансовые инструменты.
Курдль, хватит уже хрень нести. Ей Богу, утомили.

P.S. Забейте на СУБД - занимайтесь программирование.

КурдльОй, дорогуша! Похоже Вы начинаете злиться - значит я на правильном пути
На ламеров не злятся - их чмырят :)

КурдльОшибка и я ее аргументировал.
Аргументом являлось неправильное заявление. Браво.

КурдльРаботал с такими, что Вам и не снилось.


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

КурдльЗаладили, как попугай: "а что будет, если 10 миллиардов юзеров ломанутся одновременно... Не ломанутся!"
Вам виднее )

КурдльАвтоматизированные системы создаются по четким BRD, в которых указываются граничные нагрузки на них.
Много пыли - а дела в Вас нет. Ибо. Но Вы пишите, пишите :)

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

КурдльВыведите результат запроса пользователя: "Показать все документы, созданные мной за период с ... по ...!" ?!! Что, бяда? Бараны не кучкуются с арбузами?
Вы как всегда думаете задним местом, а не головой. Речь о другом шла - о ненужности наследования в угоду производительности.
Далее. Во-певых, Вы не учитывате нужность такой информации. Данная информация просто бессмысленна. Во-вторых, если уж припечёт - 4 джойна (по категориям) - и пользователь получил нужную информацию за период.

КурдльЭто делает мне честь!
Это делает из Вас мясо, а не думающего девелопера.

КурдльМожно я одним высказыванием на все предыдущие сентенции отвечу?
Да хоть сидя в припляску.

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

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

КурдльНет, конечно! Я же сказал, что не буду тратить свое время на подобные поиски.
тут

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

КурдльИ что, таблицы в БД останутся без единого следа о связи "Документ - Файл"? Вот над этим и ржу!
Про изолированность батча (читай транзакции) Вы тоже ничего не слышали?
Создаём документ => Получаем айди свежеиспеченной записи => Привязка блоба
Ржите дальше :) а мы будем работать.

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

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

КурдльКакое дело до батчей и транзакций? Я хочу узнать, Вы готовы принести в жертву поддержку целостности данных силами СУБД в угоду вездесущей и вездеср... производительности?
Так и задавайте вопрос. И Ваших же вопросов нихрена не понятно, что Вы хотите. Вот и приходится додумывать. (кстати, не умеется задавать вопросы - не первый раз уже замечаю )
В пользу производительности? Однозначно. Чем угодно пожертвую :)
Ну, а если разобраться - вопрос беспричинный. Рассмотрим вариант хранения файлов в БД (файлы вездесущих документов). Плюсы - целостность. Но, при достаточно большом кол-ве файлов (про размеры пока молчу - уже не раз писал сводки о рекомендуемом размере файла под блоб) мы получаем бубном в пах - размеры БД и удручающее по времени резервное копирование.
Выходы? Три (в разрезе сиквела, идея оракуля такая же):
1) Перенести таблцу(-ы) с файлами в отдельную БД. Минусы - ссылочная целостность идёт в печку.
2) Переносим файлы на хард. Минусы - ссылочная целостность идёт в печку.
3) Компоненты NTFS Database Engine ( FILESTREAM ). Минусы - не все еще поднялись до 2к8/R2. Во-вторых, из наставлений MS условия использования FILESTREAM - средний размер сохраняемых объектов превышает 1 МБ. А наши файлы могут быть намного меньшего размера, следовательно FILESTREAM отправляется в печку.

Ваши предпочтения: нереально долгое резервное копирование (большой размер базы) или пацанские размышления о целостности? Я выбор сделал.

P.S. Не всё так просто, Курдль, как может показать на первый взгляд. Пошевелите мозгами и Вы это поймёте. А пока, я начинаю уставать от Вашего напора сознания попиздить, а не заняться делом...

КурдльПример нетипизированной свалки(с) простейших Ценных бумаг: ...
Это не считая специфических полей и других архиважных специфических связей, которые непременно должны контролироваться механизмом поддержки целостности данных СУБД!
Уважаемый - про целостность (файлы) я уже ответил выше. Остальная целостность в полном порядке.

КурдльЗато нет сомнений, что не реже раза в день будут производиться перерасчеты рыночной стоимости всего портфеля , резервов под возможные потери и т.п. в результате чего будут формироваться распоряжения о бухгалтерских проводках.
Формируйте, в чём сложности, я реально не понимаю? Нужно выбрать - выбирайте. У нас есть 4 таблицы документов в разрезекатегории, не типа (вместо ста типизированных таблиц) - берите и выбирайте. Какие проблемы?

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

КурдльМСУ, Ну вот! А то я уж думал совсем махнуть на Вас рукой!
А ведь можете признать, что не всюду и везде разбираетесь!
Человек не может всюду и везде разбираться по определению. К чему сказали? Опять поток мыслей не по делу?

КурдльМимоходом - про файлы в БД (я привел пример навскидку и не готов отстаивать правильность хранения файлов в БД во всех случаях).
Ну вот, как коснулись реально дела - опять валите в кусты. Ну пипец, ну о чём можно с Вами поговорить? О погоде? :)

КурдльНо ни один из Ваших приемов не даст лучшей эффективности, чем перенос таблицы, содержащей БЛОБ-данные, в отдельный тэйблспейс!
Откуда такая уверенность без исходных данных (размеры, нагрузки, частота обновления и так далее в том же направлении)?

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