Не пользователь 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 таблицы документов в разрезекатегории, не типа (вместо ста типизированных таблиц) - берите и выбирайте. Какие проблемы?

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

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

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

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

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