Re[16]: В России опять напишут новый объектно-ориентированны - Компьютерные священные войны

Здравствуйте, Sinclair, Вы писали:

V>>Это не таблица движений.
S>Это та самая таблица orders, которая обычно сидит в середине star join

Я хорошо знаю базу Northwind потому что, без ложной скромности, являюсь профи по MS Access. ))

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

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

В боевой торговой системе примерно такой набор таблиц:

Мovements
 * Document [oo->1] Documents.Id
 * Commodity [oo->1] Commodities.Id
   Amount
 * Сonsignment [oo->1] Сonsignments.Id
 * Subdivision [oo->1] Subdivisions.Id

Тут 4 индекса, индекс {Document, Commodity} наиболее эффективно делать составным и кластерным.
Это таблица на оперемесяц для складского партионного учёта.

Для средневзвешенного учёта вместо Id партии товара указана себестоимость списания (за весь Amount, а не за единицу):

Мovements
 * Document [oo->1] Documents.Id
 * Commodity [oo->1] Commodities.Id
   Amount
   NetCost
 * Subdivision [oo->1] Subdivisions.Id

Тут 3 индекса.

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

Другие таблицы выглядят примерно так:

Documents
 * Id
 * ExecutionDate
   SorceDocType [oo->1] DocTypes.Id
   SourceDoc // non-relation Id of the document from different tables
 * Counterparty [oo->1] Counterparties.Id
 * Subdivision [oo->1] Subdivisions.Id

DocTypes
 * Id
   Name
   TableName // не обязательно, эти "знания" могут содержатся в коде обслуживающей программы

Orders
 * Id
   CreationDate
 * Author
   Counterparty
   ...

Основной join по классике master-slave — Documents->Movements.
Ну или два таких join по двум парам таблиц, если приход и расход живут в разных таблицах.
Для сильнонагруженных сценариев (приходы столь же часты как расходы) рекомендуется разделять таблицы прихода и расхода.
Если не разделять, то Amount и NetCost будут со знаком.

Для партионного учёта будет не один, а два join, если интересует не только кол-во, но и финансовая аналитика (нужна партия, в ней хранится цена прихода товара).

Хотя, это ХЗ. Если склад-бухгалтерия составляют одну систему, то по факту фиксации операции создаются соотв. проводки и финансовая аналитика чисто по складу вне бухгалтерии — это уже из разряда "в зубах поковыряться" или "репу почесать", т.е. такую аналитику уже удобней делать по историческим данным и OLAP.

Здравствуйте, Dym On, Вы писали:

V>>Сколько всего таблиц навроде "order" в средней системе?
DO>В моей скромной (дамп занимает всего 10Гб) учетной системе пара десятков.

У тебя прямо по этим таблицам итоги рассчитыватся?

Здравствуйте, vdimas, Вы писали:

V>Я хорошо знаю базу Northwind потому что, без ложной скромности, являюсь профи по MS Access. ))
Да я уже понял — ты во всех областях равно подкован.

V>Это не боевая система, в поделках такого уровня десятки таблиц максимум и все твои предыдущие аргументы теряют смысл, если подкреплять их подобными примерами. Тут мне опять не хватает смайлика на сравнимую величину твоей необъективности.
Угу. На самом деле всё не так, как в реальности.
Реальные системы, которые я в своей практике наблюдал — этот базы, в которых живут одновременно сотни таких нортвиндов.
Слабо связанные между собой. Это хорошо видно на диаграммах — там явно видны кластеры вокруг толстых-толстых таблиц с кучей ссылок.

V>А как организованы настоящие боевые системы, где вообще имеет смысл рассуждать о размерности задач, я уже описывал.
V>Мы выше обсуждали таблицу движений, а она связана с таблицей ордеров по одному ровно индексу.
Очень удобно — вместо разговоров о таблице orders, поговорим о таблице Movements. Ну ок, давайте посмотрим на неё. В конце концов, ты же придумываешь СУБД для работы с "твоими" базами.
Можно повнимательнее посмотреть, как оно будет работать для таких баз.

V>В боевой торговой системе примерно такой набор таблиц:
V>

V>Мovements
V> * Document [oo->1] Documents.Id
V> * Commodity [oo->1] Commodities.Id
V>   Amount
V> * Сonsignment [oo->1] Сonsignments.Id
V> * Subdivision [oo->1] Subdivisions.Id
V>

V>Тут 4 индекса, индекс {Document, Commodity} наиболее эффективно делать составным и кластерным.
Вот это интересно, продолжай. А можно показать заодно список SQL запросов, которые планируется выполнять по этой таблице?
Мне тут кое-что не нравится, но я давненько не занимался учётными системами — возможно, потерял квалификацию.

V>Другие таблицы выглядят примерно так:
V>

V>Documents
V> * Id
V> * ExecutionDate
V>   SorceDocType [oo->1] DocTypes.Id
V>   SourceDoc // non-relation Id of the document from different tables
V> * Counterparty [oo->1] Counterparties.Id
V> * Subdivision [oo->1] Subdivisions.Id

V>DocTypes
V> * Id
V>   Name
V>   TableName // не обязательно, эти "знания" могут содержатся в коде обслуживающей программы

V>Orders
V> * Id
V>   CreationDate
V> * Author
V>   Counterparty
V>   ...
V>

1. А как связаны Orders и Documents? Через SourceDocType?
2. Как мы гарантируем, что у Movement и его Document совпадают Subdivision?
3. Как выглядит код "отгрузки заказа"? Я же правильно понимаю, что мы должны из Order и его OrderDetails породить Document и Movements, одновременно подправив значения остатков в соответствующих Consignments?
Обычно как раз тут и начинается эпоха "добавления индексов", потому что наивная версия кода начинает тормозить минутами.

V>Для партионного учёта будет не один, а два join, если интересует не только кол-во, но и финансовая аналитика (нужна партия, в ней хранится цена прихода товара).
Пока что оставим вопросы финансовой аналитики в стороне. Разберёмся собственно с обеспечением движения по складу.
Аналитика нам потребуется позже — и будет интересно, можно ли внедрить её "постепенно", т.е. начав с запросов прямо по исходным данным (а почему нет, пока у нас пара сотен движений в анамнезе), и потом уже отмасштабировав на ентерпрайз-масштабы. И можно ли это делать инкрементально, без этапа "а щас подождите полгода, пока мы закупаем новое железо и пишем новую систему", потому что "основная" система продолжает развиваться и возможности остановить мир у нас нет.

Здравствуйте, alex_public, Вы писали:

[Skip]

_>Так что linq/sql подход — это всё же явно не идеал даже для работы с обычными таблицами. Что уж говорить про разные графы, документы и т.п.

_>P.S. Конечно же в некоторых РСУБД есть встроенные средства для решения указанной проблемы. Но во-первых они все не входят в стандарт SQL (я уже не говорю про linq), а во-вторых выглядят как откровенные костыли. Всё же проблема тут именно концептуальная, а не в наличие/отсутствие подходящей функции/оператора.

В linq2db мы это добавили. Это оконная функция LAG. И оконные функции вполне себе уже стандарт, только вот некоторые недобазы могут не поддерживать.

Здравствуйте, Sinclair, Вы писали:

V>>Я хорошо знаю базу Northwind потому что, без ложной скромности, являюсь профи по MS Access. ))
S>Да я уже понял — ты во всех областях равно подкован.

Это одна и та же область.
Я не раз говорил, что имел дела с VBA в количестве и с самописными ActiveX и COM-объектами на плюсах.
Это всё оно и есть.
MS Access, ИМХО, недооценённая платформа.

Беда того приложения NorthWind, что оно не показывает самые вкусности платформы.
В этой учебной базе можно в любой момент перейти в режим конструктора и "всё испортить".
В MS Access легко отделяется режим разработчика от режима эксплуатации, т.е. когда "эксплуататор" ничего не может менять и ему доступно только разработанное разработчиком меню (в том числе любые контекстные).

К тому же, его как раз было удобно использовать против MS SQL, даже еще до того, как MS SQL был поддержан "официально".
ИМХО, официально они его поддержали не правильно. Еще к MS SQL 6.x я коннектился по ODBC, при этом локальная база представляла из себя кеш.
А движок MS Jet был примечателен тем, что ему можно было пихать объединённые запросы из внешних и "своих" источников данных — это была та самая мегафишка. Есть ли еще на свете такая система, где я одним запросом достаю удалённые данные и делаю им join с некими локальными? ))

И это я уже молчу о том, что контролы MS Access — они все шли как windowless и более эффективного отображения данных в GUI (а тогда и такая эффективность была в цене) я не видел. Любое отображение только виртуальное (этот приём в конкурирующих системах только-только набирал оборот). Писать виртуальные источники данных для отображения в таблицах MS Access — одно удовольствие. Писать windowsless контролы к нему же — аналогично.

Ну и легкая связь с другими док-тами офиса, их элементарное внедрение.
В общем, по тем временам всё остальное выглядело как из 19-го века.
Особенно 1С 6.x (чисто внешне и по гибкости организации офисной работы).
Мощь 1С была в куче готовых типовых операций, соответствующих законодательству, — но это малость другая сторона, чем техническая.

V>>Это не боевая система, в поделках такого уровня десятки таблиц максимум и все твои предыдущие аргументы теряют смысл, если подкреплять их подобными примерами. Тут мне опять не хватает смайлика на сравнимую величину твоей необъективности.
S>Угу. На самом деле всё не так, как в реальности.
S>Реальные системы, которые я в своей практике наблюдал — этот базы, в которых живут одновременно сотни таких нортвиндов.

ИМХО, это наколенные поделки, разросшиеся до больших масштабов.
Пару раз я и такое видел, и?

Но любые "взрослые базы" сделаны примерно как 1C, R-base, Акцент и прочие промышленного уровня того времени.

Т.е. документы отделены от таблиц движений, отдельно идут регистры, отдельно серии временных данных (типа курсов валют).
Обязательно в явном виде присутствует операция "проводка" (транзакция, фиксирование и т.д.) и обязательно процедура закрытия периода.
Способ хранения исторических и оперативных данных отличается.
Вот как раз по индексам и ограничениям целостности в том числе.
Для read-only можно навертеть индексов сколько душе угодно.
Для оперативно изменяющихся — за это только расстрелять. ))

S>Слабо связанные между собой. Это хорошо видно на диаграммах — там явно видны кластеры вокруг толстых-толстых таблиц с кучей ссылок.

Проблема в другом — во время редактирования строк заказа в Northind, если параллельно брать остатки, то они будут "плавать".
Более того, добавь сюда другой вид документа — нужно переписывать добрую половину базы, чтобы собирать итоги из кучи таблиц-документов.
Детсад, кароч.
Такой херней дельфинисты страдали массово в середине 90-х и мы достаточно наржались в своё время с этой наивности.

Во "взрослой" системе при добавлении нового типа док-та достаточно будет реализовать его связь с таблицей движений и пару операций — проводка документа и отмена. Усё.

V>>А как организованы настоящие боевые системы, где вообще имеет смысл рассуждать о размерности задач, я уже описывал.
V>>Мы выше обсуждали таблицу движений, а она связана с таблицей ордеров по одному ровно индексу.
S>Очень удобно — вместо разговоров о таблице orders, поговорим о таблице Movements.

Именно так. Удобно.
Потому что тяжеловесное обращение к Orders относительно "однократное" — в момент проводки.

V>>В боевой торговой системе примерно такой набор таблиц:
S>1. А как связаны Orders и Documents? Через SourceDocType?

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

Через "чистую реляцию" никак не связаны, насколько ты успел понять (надеюсь).
В рамках транзакции меняется состояние док-та из Orders и появляется, либо исчезают строки из Documents и Movements.

Таких Orders в большой системе — многие десятки, а то и больше сотни.
Например: акты возврата от покупателя, акты списания, резервирование от клиента, резервирование от фирмы, переброс товаров в акционные, объединение товаров в новые товары (сборки) или обратно, разбиение товара по "цветам" или обратная "монохромная сборка", ликвидация "цветной" пересортицы — т.д. и т.п., это зависит от конкретной предметной области.

Но таблица движений ТМЦ — одна.
Ну или две в случае оформления приходов и расходов в виде отдельных таблиц.

S>2. Как мы гарантируем, что у Movement и его Document совпадают Subdivision?

Да там не только это надо гарантировать.
Начинать надо с DocumentId.
Твой вопрос более общий: как гарантировать целостность данных в условиях избыточности или отсутствия связей, гарантирующих целостность данных?
Известное решение одно — транзакции.

Моя эволюция:
— сначала расписал на триггерах, где изменения состояния order провоцируют проводку док-та или его отмену с соотв. изменениями таблицы движений и документов. Однажды отчетный период затянулся на 3 месяца и база стала спотыкаться.
— переписал просто на хранимки — это примерно втрое эффективней, чем на триггерах.
— а потом и вовсе отказался от некоторых встроенных ограничений целостности, например от внешнего ключа — еще в 3-5 раз получил прирост.

Далее я сузил многие суррогатные ключи с 32-х до 16-ти бит в сотнях таблиц и неожиданно получил прирост скорости еще вдвое, что аж стало любопытно, бо в 32-х разрядной системе такие вещи не ускоряют, а замедляют. По крайней мере при работе с памятью. Что аж достал по-блату исходники 6-го MS SQL и примерно 3 дня из любопытства разглядывал на длиннющем распечатанном рулоне (матричные принтеры — рулез). ))

Причём, увеличение оперативки сервака такого прироста не дало, дело было в чём-то другом.
После серии экспериментов стало понятно, что физический размер индекса играет рояль.

S>3. Как выглядит код "отгрузки заказа"? Я же правильно понимаю, что мы должны из Order и его OrderDetails породить Document и Movements, одновременно подправив значения остатков в соответствующих Consignments?

Именно так.

S>Обычно как раз тут и начинается эпоха "добавления индексов", потому что наивная версия кода начинает тормозить минутами.

Это стандартный master-slave, как делать для него составной ключ — уже показал.
Заметь, что в таблице движений нет уникального ключа.
Уникальные ключи тоже зло и тормоза, увы.

S>Аналитика нам потребуется позже — и будет интересно, можно ли внедрить её "постепенно", т.е. начав с запросов прямо по исходным данным (а почему нет, пока у нас пара сотен движений в анамнезе)

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

S>и потом уже отмасштабировав на ентерпрайз-масштабы.

Подход Northwind не масштабируется от слова никак.
Моя первая система была примерно в таком же виде, потом я устал править сотни запросов при добавлении каждой новой операции и отделил мух от котлет. Мне хватило полугода одновременной эксплуатации и развитием системы (до этого контора выписывала накладные в MS Excel, потом расширилась и перестала справляться).

Потом некоторое время ставил и по другим конторам новое поколение своих поделий (в каждом конкретном случае всё-равно много уникального было), обслуживал их. Ну и насмотрелся на варианты учётных систем, которые заменял своей.
Тогда было их жуткое разнообразие, не то, что сейчас.

А по природе я любопытен, со всеми вытекающими.
В итоге вышло примерно как с той книжкой GoF — ничего нового.
Разве что подсмотрел у 1C прикольный способ хранения временных серий данных — это было их, не побоюсь этого слова, ноу-хау, тут они молодцы.
Остальное — примерно так же или хуже, чем у меня. ))

Например, мой любимый способ представления иерархических данных строг и шустр, хоть и избыточен.
(связь от каждого узла к каждому Parent+расстояние)

Ну и часто наблюдал, что в учётных системах отсутствует возможность накрутить более одной иерархии для тех же данных.
Например, над товарами потенциально можно накрутить несколько слабо пересекающихся иерархий.
Кол-во иерархий зависит от типа товара.
В 1С была всегда одна иерархия, а как клиенты узнавали о такой возможности, то я менее 2-х иерархий не видел.
Три — самое популярное их число.

S>И можно ли это делать инкрементально, без этапа "а щас подождите полгода, пока мы закупаем новое железо и пишем новую систему", потому что "основная" система продолжает развиваться и возможности остановить мир у нас нет.

Так нельзя.
У меня не получилось, только время потратил в кол-ве 2-х месяцев траха.
Потому разделение "исходников" от "движений" — оно фундаметальное.
Оно или есть, или его нет.
За меньшее время я потом с 0-ля сделал систему с таким разделением (и был доволен собою как слон, справедливости ради... да и было мне тогда 26-27).

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>>За 10-15 индексов по order положено расстреливать, ну пусть даже 10-15 индексов.
DO>>Откуда такая индексофобия

?
НС>От отсутствия реального опыта. Неужели из топика еще непонятно?

Что характерно, что все 2.5 моих регулярных оппонента спорят до хрипоты по одной и той же причине — от отсутствия профильного образования.
Это пока единственная выявленная корелляция.

Здравствуйте, vdimas, Вы писали:
V>ИМХО, это наколенные поделки, разросшиеся до больших масштабов.
V>Пару раз я и такое видел, и?
И отлично работает в продакшне. Особенно если пригласить компетентного DBA с пониманием того, как сервер

S>>Очень удобно — вместо разговоров о таблице orders, поговорим о таблице Movements.

V>Именно так. Удобно.
V>Потому что тяжеловесное обращение к Orders относительно "однократное" — в момент проводки.
Это если нам неинтересны ордера. Как правило, как раз интересны — всякие отчёты типа "сравнить работу менеджера по продажам в текущем месяце с предыдущим" и прочие — они ж не по таблице движений будут делаться.
Ну, отложим пока в сторонку.

V>Через "чистую реляцию" никак не связаны, насколько ты успел понять (надеюсь).
V>В рамках транзакции меняется состояние док-та из Orders и появляется, либо исчезают строки из Documents и Movements.
Отлично, отлично.

S>>2. Как мы гарантируем, что у Movement и его Document совпадают Subdivision?

V>Да там не только это надо гарантировать.
V>Начинать надо с DocumentId.
V>Твой вопрос более общий: как гарантировать целостность данных в условиях избыточности или отсутствия связей, гарантирующих целостность данных?
V>Известное решение одно — транзакции.

S>>3. Как выглядит код "отгрузки заказа"? Я же правильно понимаю, что мы должны из Order и его OrderDetails породить Document и Movements, одновременно подправив значения остатков в соответствующих Consignments?
V>Именно так.
Давайте закопаемся в детали.

V>Заметь, что в таблице движений нет уникального ключа.
V>Уникальные ключи тоже зло и тормоза, увы.
Ухтыжблин! А что, есть какой-то более быстрый способ гарантировать уникальность? Вопрос риторический, можно не отвечать.

V>"Полуаналитика" тоже нужна. Например, у меня была таблица "товары на резерве".
Вот я как раз про это.
V>Т.е. вот десятки девочек выписывают накладные, они видят в каждой строке одни и те же остатки.
V>В наивном виде это будут остатки по факту проводки документов, а для целей выписки нужны остатки с учётом выписываемого за соседним столом в ту же секунду.
Да-да-да. Ну, давайте хотя бы процедуру отгрузки ордера набросаем, посмотрим, как она будет устроена, и будут ли нам индексы мешать или помогать.
Потом добавим расчёт "мгновенных остатков" с учётом заказов в статусах "пред-резерв". А потом уже будем смотреть, что можно накрутить без особой потери производительности.
Какова будет общая схема кода? Или давайте допишем хотя бы схемы таблиц OrderDetails и Consignments — попробую тряхнуть стариной и написать код сам. Вместе посмеёмся потом.

V>Например, мой любимый способ представления иерархических данных строг и шустр, хоть и избыточен.
V>(связь от каждого узла к каждому Parent+расстояние)
Это называется "транзитивное замыкание", и не "изобрёл" его только ленивый.

V>Так нельзя.
V>У меня не получилось, только время потратил в кол-ве 2-х месяцев траха.
У меня — получалось.

Здравствуйте, Sinclair, Вы писали:

V>>ИМХО, это наколенные поделки, разросшиеся до больших масштабов.
V>>Пару раз я и такое видел, и?
S>И отлично работает в продакшне.

В мире многое чего происходит не благодаря, а вопреки. ))

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

Или тут рядом говорили о 10 гигах в логе, забыли сказать — за какой период.

V>>Потому что тяжеловесное обращение к Orders относительно "однократное" — в момент проводки.
S>Это если нам неинтересны ордера. Как правило, как раз интересны — всякие отчёты типа "сравнить работу менеджера по продажам в текущем месяце с предыдущим"

Отчет раз в месяц по read-only данным?
После закрытия периода и подведения итогов?

V>>Заметь, что в таблице движений нет уникального ключа.
V>>Уникальные ключи тоже зло и тормоза, увы.
S>Ухтыжблин! А что, есть какой-то более быстрый способ гарантировать уникальность?

Я тут неверно выразился.
Нет суррогатного уникального ключа.
Чтобы гарантиоровать что-то там по суррогату сначала надо определиться — а нужен ли сам суррогат?

S>Вопрос риторический, можно не отвечать.

Вопрос не риторический, а жульнический.

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

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

Тема вообще смешная, кста. По-факту в тех самых "реальных системах" я наблюдал не раз обеспечение уникальности суррогатных ключаей в тех местах, где этого не требовалось. Не потому не требовалось что, мол, и без базы сами обеспечим, а потому что она там не нужна прямо согласно предметной области. Сам суррогатный ключ не требовался.

И это речь о тех самых "квалифицированных DBA", которые хорошо умеют тюнить имеющуюся схему, но плохо понимают, почему эта схема именно такая. Да и, положа руку на сердце, грамотно раскидать данные по таблицам — во все времена было исскуством. Northiwind в этом смысле тот самый Ад и Израиль. (С)

Популярные в начале 2000-х руководства и куча инструментария по доменному моделированию предметных областей приводили к рождению монстров. Потому что не может непрофессионал заниматься разработкой схемы хранения данных.

А любой DBA — это непрофессионал от IT, эдакий гастарбайтер, — такое железное правило сложилось как раз в 90-2000-х годах и вовсе не только на просторах СНГ, в Штатах ровно аналогично. Всё из-за программистских зарплат. Причём, даже если чел имеет IT-образование, но как "честный программист" не удался, то хватается или за HTML или за DBA. Это та самая классика жанра.

В этом смысле дотнет, помнится, натурально спас всю эту прослойку, бо позволил утилизировать её в виде, таки, снова программистов, а не только лишь обслуги имеющегося софта.

А схемы-уродцы получались по той причине, что пытались мыслить абстрактно.

Любое проектирование там пляшет от суррогатного ключа и далее по тексту. А что каждое лишнее поле в таблице и каждый лишний индекс — это приближение той самой оп-пы — в голову не приходит. ))

IT до сих пор, заметь, больно бъет за попытки мыслить слишком абстрактно.
Особенно это стало заметно из-за мобильного сегмента, где эффективность опять в цене.

V>>В наивном виде это будут остатки по факту проводки документов, а для целей выписки нужны остатки с учётом выписываемого за соседним столом в ту же секунду.
S>Да-да-да. Ну, давайте хотя бы процедуру отгрузки ордера набросаем, посмотрим, как она будет устроена, и будут ли нам индексы мешать или помогать.
S>Потом добавим расчёт "мгновенных остатков" с учётом заказов в статусах "пред-резерв". А потом уже будем смотреть, что можно накрутить без особой потери производительности.
S>Какова будет общая схема кода? Или давайте допишем хотя бы схемы таблиц OrderDetails и Consignments — попробую тряхнуть стариной и написать код сам. Вместе посмеёмся потом.

Тряхни, какие проблемы?
Обещаю внимательно посмотреть.

V>>Например, мой любимый способ представления иерархических данных строг и шустр, хоть и избыточен.
V>>(связь от каждого узла к каждому Parent+расстояние)
S>Это называется "транзитивное замыкание", и не "изобрёл" его только ленивый.

Э-э-э. Вообще-то 3-я нормальная форма явно требует разрывать транзитивные замыкания, а не создавать их. ))
Это всё еще про tradeoff между нормализацией и денормализацией.
Т.е., порой никуда от избыточности не денешься.

V>>У меня не получилось, только время потратил в кол-ве 2-х месяцев траха.
S>У меня — получалось.

Не верю.

Поясню.
При пошаговом изменении приходилось после каждого шага править сотни запросов, в т.ч. для отчётов и аналитики.

Что такое "пошагово"? — это когда на указанную схему исходник->движения различные типы документов переезжают по-одному.
Дешевле оказалось перевести все документы сразу и тем самым переписать сотни запросов лишь однажды.
Я просто измерил скорость и увидел, что требуется около года на пошаговый переезд. Для переезда с 0-ля мне хватило пары месяцев.

Понятно, что было очень много чего переиспользовано из уже готовой системы (отчёты, контролы, формы, хелперы и т.д.). Но схема данных была раздизайнена с 0-ля и она оказалась весьма живучей, в том плане, что на её основе была сделана куча модификаций для разных специфик.

Т.е. оказалось дешевле переписать всё с 0-ля и подготовить скрипты импорта из живой системы. В один прекрасный день данные просто переехали на новую систему.

Здравствуйте, vdimas, Вы писали:

V>Например:
V>

V>float calcWeght_ScanByIndex_Table1_Index1(int value);
V>

V>Эта процедура повторно используется (вызывается) из многих процедур оценки планов, где план подразумевает выборку из Table1 через Index1.

V>Еще:
V>

V>float calcWeght_ScanByIndex_Table1_Index2_Range(DateTime minValue, DateTime maxValue);
V>

V>Думаю, смысл понятен.

Смысл понятен, но есть некоторые сомнения, что нынешний синтаксис и семантика sql позволит такое. Например, в cassandra пришлось разработать довольно урезанный вариант sql, который бы лег под их модель (которая как раз очень жестко заранее определена — прямо как у тебя, даже более жестко). Там речь идет в основном об условии where — они должны образовывать строгую иерархию, столбцы должны фигурировать в условиях в порядке их объявления в схеме, и пропуски не допустимы. То есть ты не можешь, например, пропустить столбец номер 2 и ограничить столбец номер 3. Ну и там куча других ограничений на диапазоны и пр., все не буду писать, если интересно, найти очень просто.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, LaPerouse, Вы писали:

LP>>Какого хочешь. Проще всего так:
LP>>

LP>>List<Object[]> result = em.createQuery(query, Object[].class).getResultList();
LP>>

НС>

Что не так? Подозреваю, что передача класса вместо явной параметризации, но все прекрасно осведомлены, почему в яве делается именно так, а не иначе, зачем истерику-то закатывать?

Здравствуйте, Danchik, Вы писали:

D>Как решать так и создавать проблемы.
D>Только не зная что нам дает linq я тут буду долго бится об стенку обьясняя его преимущества.

Не зная того, то дает настоящий современный орм, только и остается биться о стенку.

Коротко посмотрел на линк. Это дно, это уровень, который ява прошла много лет тому назад. Обычный java jdbc, приправленный сомнительным дсл-ем, весьма непонятным и малоинтуитивным.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>От отсутствия реального опыта. Неужели из топика еще непонятно?

Да, насчёт опыта.
Ты же вроде над "Парусом" работал или работаешь?
А ты вообще знаешь, что это? ))
Это несколько бывших офицеров ВМФ из Севастополя замутили.
Сначала накатали несколько модулей для зарплаты, потом немного бухгалтерии.
В 95-м году решили собрать в единую систему управления предприятием, т.е. еще плюс склад и кадры.
На Дельфи, ы-ы-ы.
Я как раз институт закончил и поучаствовал, как раз эти модули отдали в Севастополь и вообще, чтобы "склеили это всё".
Команда примерно 15 человек, средний возраст 19-22 года.
Ну, склеили как могли. ))
Я потом еще несколько лет следил за судьбой этого детища.
С печалью отмечал, что как слепили из г-на и палок, так оно и осталось.
Вместо того, чтобы сделать полноценный конструктор, так и осталась ситема наколенных т.н. "модулей".
Там, где справлялся один одинэсник, там надо было 5-10 человек для Паруса, бо всё ручками.
Типа как китайцы решат любую задачу, потому что их миллион.

Т.е. цимус в том, что как мы студентами эту кучу г-на вывалили, так вы её десятилетиями и обслуживаете.
И тут такое вылупилось из яйца и ну давай курицу учить, про свой опыт рассказывать.

Тут мало того, что сам Дельфи неумолимо провоцирует на спекание мух, котлет и макаронного кода воедино...
Так еще мы сами отдавали себе отчёт в бардаке архитектуры.
Да и за ту ЗП особо не парились.
Это уж если совсем по чеснаку.
Так, чиста в зубах поковырять, пообщаться и поржать.
Тем более загадочной получилась дальнейшая судьба продукта.
По крайней мере для меня, я так и не понял произошедшего.

Похоже, на спокойное приятие этого бардака повлиял эффект загадочности.
Просто тут народ стал постепенно разъезжаться по заграницам (платили-то копейки), работать некому, разработка переехала в Москву.
Там бесплатников побольше будет. А местные, московские, походу, увидели и такие: "ва-а-ау, какая сложная система!"
И давай на неё молиться, пылинки сдувать, да тщательно имитировать через натуральный карго-культ другие модули расширения.

Кароч. Спустя 5 лет взять те системы, которые я писал, — Парус с ними и рядом никогда не стоял.
Между Парусом и теми системами — 5 лет моего опыта, а это для вчерашнего студента много, целая вечность.
Парус на такой технике и таких оборотах банально не жил, потому что это нубское поделие от самого своего рождения и от его извращённого способа. Опыт разработки для Паруса всегда резко отрицательный — вы опускаетесь на уровень тех самых решений "по-месту", как недоучившиеся студенты.
Ну просто мы по-другому тогда не умели, извините нас. ))

Здравствуйте, LaPerouse, Вы писали:

LP>Там речь идет в основном об условии where — они должны образовывать строгую иерархию, столбцы должны фигурировать в условиях в порядке их объявления в схеме, и пропуски не допустимы.

Похоже на бета-версию, выпущенную в продакшен.

Изначально проект был разработан в недрах Facebook

Ну, всё понятно, внутренний тул выполз наружу.

Кстате, форк Кассандры на С++:
https://www.scylladb.com/wp-content/uploads/datasheet_why-scylladb.pdf
Пишут про 10х раз увеличенное быстродействие.

Там, где надо было 30 узлов на Джаве, там справляется 3 на нейтиве.
А современный SQL сервак работает еще хуже Джавы.
Т.е. не такая уж моя идея глупая. ))

Здравствуйте, vdimas, Вы писали:

V>И воровство при такой организации "учёта" обычно цветёт и пахнет, потому что достаточно поменять строчки заказа (цену в них или кол-во) и вся отчётность автоматом "плывёт". Разницу можно себе в карман. Наблюдал более 3-х раз вживую.
Это ортогональный вопрос. Возможность попатчить движения и остатки совершенно не зависит от того, сколько там участвует таблиц.

S>>Это если нам неинтересны ордера. Как правило, как раз интересны — всякие отчёты типа "сравнить работу менеджера по продажам в текущем месяце с предыдущим"
V>Отчет раз в месяц по read-only данным?
V>После закрытия периода и подведения итогов?
Ежедневно в течение активного периода. После закрытия месяца уже поздно мотивировать менеджера.

V>Я тут неверно выразился.
V>Нет суррогатного уникального ключа.
V>Чтобы гарантиоровать что-то там по суррогату сначала надо определиться — а нужен ли сам суррогат?
В таком случае — норм.

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

И опять начинается некомпетентная чушь.

S>>Какова будет общая схема кода? Или давайте допишем хотя бы схемы таблиц OrderDetails и Consignments — попробую тряхнуть стариной и написать код сам. Вместе посмеёмся потом.

V>Тряхни, какие проблемы?
схемы таблиц OrderDetails и Consignments — в студию. А то вдруг я их неправильно придумаю

V>Обещаю внимательно посмотреть.

V>Э-э-э. Вообще-то 3-я нормальная форма явно требует разрывать транзитивные замыкания, а не создавать их. ))
Так и любой индекс является денормализацией — по определению. Он же вводит "вычисляемые" отношения в чистую реляционную модель. Взрослые люди понимают, что бывают индексы, поддержанные на уровне СУБД, но они не исчерпывают все возможности по оптимизации. Поэтому может потребоваться вводить "рукопашные" индексы, теряя возможность автоматической оптимизации запросов.
Вот, хранение остатков — это один из вариантов такого индекса. Транзитивное замыкание — другой. Нормализация базы нужна не сама по себе (иначе это — культ карго), а для достижения определённых целей.
К сожалению, это мало кто понимает. Вот и возникают всякие идиотизмы типа раздельных полей для улицы/дома в адресе (несмотря на то, что никогда не планируется делать запросов типа "сумма заказов с доставкой на улицу Ленина в любом городе любой страны"), или "код страны — код города — телефон".

V>При пошаговом изменении приходилось после каждого шага править сотни запросов, в т.ч. для отчётов и аналитики.
V>Что такое "пошагово"? — это когда на указанную схему исходник->движения различные типы документов переезжают по-одному.
Я не про перевоз документов. Я про то, что у нас были отчёты, которые строились по актуальным данным. Потом они начали тормозить, и появились идеи "а давайте удвоим уже потраченную стоимость разработки, и всю отчётность перенесём на внешний OLAP сервер, настроив репликацию".
Оказывается, что вполне можно аккуратно проапгрейдить схему базы, почти не трогая клиентов, так, чтобы и отчёты работали, и OLTP летал.
Вот, к примеру, на моей нынешней работе идея "давайте реплицировать данные во внешнюю BI систему" муссируется уже лет пять. Воз и ныне там — оценки стоимости этого решения превышают разумный бюджет, его ежегодно откладывают "на следующий год". С тех пор компания пережила два слияния, одно разделение и одно поглощение — фича по-прежнему в роадмапе.
А под тем предлогом, что "ну это же правильное решение, которое всё равно мы будем делать рано или поздно" существующие отчёты по актуальным данным никто не развивает. Клиенты плачут и жалуются, а лично меня это бесит.
К сожалению, я слишком далёк от той части компании, которая занимается этим вопросом, и сделать ничего не могу. А вот до этого я работал в бодишопе, и к нам регулярно приходили заказы вроде "у нас есть учётная система, она прекрасно работает, кроме вот этих вот пяти мест — можете помочь?". И мы регулярно помогали. При этом без написания целой системы с нуля. Это зачастую вообще невозможно, потому что у мало-мальски развитой системы не существует покрывающей документации. В одну и ту же базу лазят клиенты на Дельфи, джавовский миддл-тиер, и тонна страничек на классическом ASP. А может и ещё что-нибудь, написанное в 1997 году контрактором и давно забытое.
Понять, кто зависит от структуры таблицы SurveyResponses — невозможно, т.к. нет даже способа получить все исходники зависимых систем.
Это означает, что мы принципиально не можем оценить стоимость проекта — может $100k, а может — $1m. "Как пойдёт".
Заказчики почему-то не согласны платить неизвестные заранее деньги и тратить неизвестное заранее время на решение, которое не имеет гарантированных преимуществ.
Поэтому они были очень рады, когда за $30k и две недели им чинили ровно эти пять мест, не ломая ничего из старого кода.

Здравствуйте, Sinclair, Вы писали:

V>>И воровство при такой организации "учёта" обычно цветёт и пахнет, потому что достаточно поменять строчки заказа (цену в них или кол-во) и вся отчётность автоматом "плывёт". Разницу можно себе в карман. Наблюдал более 3-х раз вживую.
S>Это ортогональный вопрос. Возможность попатчить движения и остатки совершенно не зависит от того, сколько там участвует таблиц.

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

Да, это побочный эффект, но весьма забавный.
Несколько контор взяли мою систему в том числе потому что она позволяла защититься от воровства — достаточно было дать возможность проводить и отменять документы одному материально-ответственному лицу и усе.

V>>Отчет раз в месяц по read-only данным?
V>>После закрытия периода и подведения итогов?
S>Ежедневно в течение активного периода. После закрытия месяца уже поздно мотивировать менеджера.

Мотивирование — оно обычно деньгами, а "менеджеры" в торговых предприятиях — это просто девочки на выписке накладных.
Ну ОК, пусть активно, пусть даже каждый день хотя бы по разу для каждой девочки.
Такая "нагрузка" не стоит обсуждения, ИМХО.

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

S>И опять начинается некомпетентная чушь.

Да ладно, это чуть ли не норма — делать суррогатные ключи с автонумерацией.
Как раз в тех самых наколенных поделках цветёт и пахнет.

V>>Э-э-э. Вообще-то 3-я нормальная форма явно требует разрывать транзитивные замыкания, а не создавать их. ))
S>Так и любой индекс является денормализацией — по определению.

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

S>Он же вводит "вычисляемые" отношения в чистую реляционную модель.

В механику её реализации, а не в саму модель.
"Модель" — это то, что для человека, а не для машины. ))

S>Взрослые люди понимают, что бывают индексы, поддержанные на уровне СУБД, но они не исчерпывают все возможности по оптимизации. Поэтому может потребоваться вводить "рукопашные" индексы, теряя возможность автоматической оптимизации запросов.

Какое вольное обращение с терминологией.
Вики:

Индекс — объект базы данных, создаваемый с целью повышения производительности поиска данных.

S>Вот, хранение остатков — это один из вариантов такого индекса.

Остатки — это "регистры". Даже с учётом вольности терминологии, таки, есть принятое другое название в этой предметной области.
И то и другое индексами не является.

Индексы служат для быстрой навигации к нужным строкам БД.
Всё остальное — не индексы.

Твоё их понимание, заметь, уже не впишешь во "всего лишь широкое толкование".

Похоже, под индексами ты понимаешь эдакую "специальную копию/проекцию" самих данных или вычисляемых.
Но это всего лишь один из механизмов реализации индекса.
Индекс может быть вычисляемым, но при этом содержать данные, которых нет ни в одном оперируемом view.
Например, для хронологических данных индекс может содержать "склейку" периодов, а глупый программист и знать не будет, что у него нарисовалась вертикальная избыточность (тоже болезнь всех без исключения виденных наколенных поделок без отдельного механизма обслуживания периодических данных).

Кароч, пародируя твои же манеры порождения аргументов: хотя яблоки бывают красными, не всякое красное является яблоком.
))

S>Транзитивное замыкание — другой.

Если это не специальный объект базы, а просто данные в таблицах, т.е. это просто избыточность.

S>Нормализация базы нужна не сама по себе (иначе это — культ карго), а для достижения определённых целей.

Исторически эти цели были просты — для наиболее дешевого обеспечения целостности данных при последовательном к ним доступе.

В 5/6-й нормальных формах избыточные данные банально некуда писать.
Например, база Northwind не находится в 5-й нормальной форме хотя бы даже из-за поля ShipCity.

S>К сожалению, это мало кто понимает. Вот и возникают всякие идиотизмы типа раздельных полей для улицы/дома в адресе

Это идиотизм не потому что в БД есть запреты, а потому что бывают адреса без улицы, без домов и вообще в свободной форме.
Т.е. сама предметная область НЕ диктует такого разделения.

Хотя, в тех же госуслугах именно есть база домов и квартир, т.е. если согласно предметной области требуется именно такой учёт, то он
и реализуется, ес-но.

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

Если есть мотив двигаться на конкретное рабочее место — то надо двигаться.

S>А вот до этого я работал в бодишопе, и к нам регулярно приходили заказы вроде "у нас есть учётная система, она прекрасно работает, кроме вот этих вот пяти мест — можете помочь?". И мы регулярно помогали. При этом без написания целой системы с нуля. Это зачастую вообще невозможно, потому что у мало-мальски развитой системы не существует покрывающей документации. В одну и ту же базу лазят клиенты на Дельфи, джавовский миддл-тиер, и тонна страничек на классическом ASP. А может и ещё что-нибудь, написанное в 1997 году контрактором и давно забытое.
S>Понять, кто зависит от структуры таблицы SurveyResponses — невозможно, т.к. нет даже способа получить все исходники зависимых систем.
S>Это означает, что мы принципиально не можем оценить стоимость проекта — может $100k, а может — $1m. "Как пойдёт".
S>Заказчики почему-то не согласны платить неизвестные заранее деньги и тратить неизвестное заранее время на решение, которое не имеет гарантированных преимуществ.
S>Поэтому они были очень рады, когда за $30k и две недели им чинили ровно эти пять мест, не ломая ничего из старого кода.

Мде. Если бы я за две недели чинил пять мест в SQL, я бы никогда ничего не написал бы.

Не, у нас ходили байки, что в больших городах у программистов скорость написания кода низкая (мы сравнивали — разница до 20-ти раз на проектах среднего уровня), просто я как-то упустил из виду, что к SQL это тоже относится. ))

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

================
Ладно, всё это интересно, но уже давно не о том.
Ты хотел провести сам для себя сравнительный эксперимент схемы отдельными движениями — проведи.
Там не сложно.
Но для эфекта надо провести хотя бы на двух-трех типах складских документов, иначе эффект будет не заметен.

Еще ты хотел посмотреть на движки работы с таблицами напрямую?
Помимо InnoDB есть еще Btrive (как я мог запамятовать?)
Это тоже законченный ISAM-модуль, поверх которого работает движок PSQL.

И да, твои претензии к ISAM от непонимания, вестимо.
Тот же MS SQL — это банальный сервис над ISAM, т.е. непосредственный доступ к данным в данный момент времени имеет только одна программа.
В плане обсуждаемой системы "без SQL" это ни на что не влияет.

Здравствуйте, LaPerouse, Вы писали:

LP>Здравствуйте, Danchik, Вы писали:

D>>Как решать так и создавать проблемы.
D>>Только не зная что нам дает linq я тут буду долго бится об стенку обьясняя его преимущества.

LP>Не зная того, то дает настоящий современный орм, только и остается биться о стенку.

Ну пипец, я состою в разработке легковесной ORM, и да я знаю что предлагают современные ORM типа Hibernate и EF — тормоза на ровном месте, зато солнце заходит само ))
Когда уже кеши не помогают, SQL сервер некуда апгрейдить — пилятся костыли в виде SQL. Отрубаются кеши, отрубают Lazy load, внимательно просматривают какого милого эти подчиненные записи тянулись. Боже, как же это все помогало то сначала. И джуники были заняты и рапортовали вовремя, а пришел злой продакшин и понеслась.

Change tracker — блин все было с ним хорошо. Но удалить/проапдейтить 1000 записей им глупо
Да и не всегда тебе нужно запись тянуть чтобы апдейтать. Как правило и не надо, с клиента приходит модель, которую уже или после трансформации можно в базу прокидывать.

LP>Коротко посмотрел на линк. Это дно, это уровень, который ява прошла много лет тому назад. Обычный java jdbc, приправленный сомнительным дсл-ем, весьма непонятным и малоинтуитивным.

Вот сразу же говорил — что бится об стенку ))
Яве бы взять и поддержать сей DSL

> весьма непонятным и малоинтуитивным.
Это интерсно почему? Он похож на SQL и даже очень.

Вот вьюшки Northwind для теста пергнаны на linq
https://github.com/linq2db/linq2db/blob/master/Tests/Tests.Benchmark/NortwindExtensions.cs

Вперед используй их в запросах — query decomposition в полный рост.

Здравствуйте, vdimas, Вы писали:

V>Зато безопасность зависит.
V>Когда у нас доступ к разным таблицам, то можно пользовать родную безопасноть серваков на основе ролей.
V>А когда речь о доступе к одной и той же, то безопасность тут обеспечивается лишь приложением, но всегда можно приконнектиться в обход приложения и поправить цифирки.
Начинаются бесплодные теоретизирования. Доступ на уровне ролей устроен так: если внесение изменений в таблицу "движение", выполняемое совместно с внесением изменений в таблицу "остатки", делается под учёткой пользователя, то он и без приложения может пойти и поправить обе таблицы.
В двухзвенной системе у пользователей прав на insert и update на эти таблицы нет, а есть только право выполнения хранимой процедуры.
При такой раздаче ролей нам неважно, в скольки таблицах это работает.

V>Да ладно, это чуть ли не норма — делать суррогатные ключи с автонумерацией.
Совершенно верно. При этом нет никакой нужды (а зачастую и возможности) знать значение ключа перед вставкой. Как раз требование "знать значение ещё до вставки" может, в зависимости от используемой СУБД, существенно просадить производительность. Особенно если избегать делать индекс по этому ключу. Перед тем, как вынимать линейку, надо матчасть выучить.

V>Индекс согласован с данными "автоматически", прозрачно для тебя.
Это уже детали реализации. В нашей системе транзитивное замыкание тоже согласовывалось автоматически и прозрачно, ибо триггеры. Единственное, чем оно было хуже встроенных индексов — необходимостью использовать его явно. Но об этом я уже говорил.

V>В этом сама суть ISAM-подхода (на который ты однажды накинулся, ХЗ зачем).
Алиса, никогда не повторяй слова только за то, что они умные и красивые.
ISAM-подход — он не про то, что индексы обновляются прозрачно. А про то, как расположены записи внутри таблицы — последовательно, фиксированного размера.
На всякий случай напомню, что в SQL Server никакого ISAM нет, а индексы как раз есть, и вполне себе автообновляемые.

V>А избыточные данные юзверского уровня запросто могут находиться в несогласованном состоянии.
Например, full-text индексы, как правило, надо перестраивать вручную. Несмотря на это, их всё ещё называют индексами.

V>Вики:
V>

V>Индекс — объект базы данных, создаваемый с целью повышения производительности поиска данных.

Совершенно верно. А для чего ты вводил транзитивное замыкание? Уж не для того ли, чтобы ускорить поиск данных?

V>Остатки — это "регистры". Даже с учётом вольности терминологии, таки, есть принятое другое название в этой предметной области.
V>И то и другое индексами не является.
Смотря что считать предметной областью. Если RDBMS — то нам ничто не мешает сначала сделать view, которое будет вычислять group by от истории движений, а потом приклеить к нему индекс.
И внезапно вместо "регистров", наша штука станет называться "materialized view", или "indexed view", в зависимости от использованной платформы.

V>Похоже, под индексами ты понимаешь эдакую "специальную копию/проекцию" самих данных или вычисляемых.
Да. Именно так и устроены все индексы — они хранят результат вычисления некоторой операции над пользовательскими данными.
V>Но это всего лишь один из механизмов реализации индекса.
V>Индекс может быть вычисляемым, но при этом содержать данные, которых нет ни в одном оперируемом view.
V>Например, для хронологических данных индекс может содержать "склейку" периодов, а глупый программист и знать не будет, что у него нарисовалась вертикальная избыточность (тоже болезнь всех без исключения виденных наколенных поделок без отдельного механизма обслуживания периодических данных).
Совершенно верно. И это — тоже частный случай. Просто наше "view", помимо select и group by, содержит ещё и union all.
Есть много видов индексов. Какие-то из них обновляются автоматически, какие-то — вручную, какие-то ускоряют запросы автоматически, а какие-то надо применять явно.
Один из частных случаев называется "регистрами". Знать это важно для обсуждения с сотрудникми бухгалтерии (откуда и взят этот термин), но разработчик, претендующий на улучшения существующих СУБД должен понимать, что это — всего лишь частный случай индексированного вью.

S>>Нормализация базы нужна не сама по себе (иначе это — культ карго), а для достижения определённых целей.
V>Исторически эти цели были просты — для наиболее дешевого обеспечения целостности данных при последовательном к ним доступе.
Опять вроде начинаем правильно, а потом выруливаем в чушь. Наиболее дешёвого — да. Целостности — не только: ещё и для экономии дискового пространства и ускорения запросов. Последовательный доступ — вообще мимо.
Нормализация применяется и актуальна и для последовательного, и для параллельного, и для произвольного доступа.
V>Это идиотизм не потому что в БД есть запреты, а потому что бывают адреса без улицы, без домов и вообще в свободной форме.
Вот именно. Если адрес нужен только для того, чтобы напечатать его на конверте, то и хранить его нужно в виде строки для печати на конверте, а не в виде набора из семи полей, любые из которых могут быть пустыми.

V>Если есть мотив двигаться на конкретное рабочее место — то надо двигаться.

Компания — огромная, я — один. Пока что я двигаюсь от написания кода к принятию продуктовых решений — типа что и когда мы запускаем.

V>Мде. Если бы я за две недели чинил пять мест в SQL, я бы никогда ничего не написал бы.
V>Ребят, сорри, я вас иногда читаю — вы, блин, тепличные растения, жизни не нюхавшие.
V>Претензии на какой-то там "повышенный опыт", в сравнении с коллегами — ну они улыбают (это если цензурно).
V>Те задачи, которые решают настоящие боевые программисты, давай уж по-чеснаку, вы бы за эти задачи даже не взялись.
V>Только морщили бы носик и крутили у виска.
V>В лучшем случае выкатили бы в 10 раз больший бюджет и в 10 раз были бы больше требования к железу.
Пока что предложения с большим бюджетом в данном треде — только от тебя. Это же ты нам втираешь, что в неспособен написать систему, где отчётность строится по актуальным данным. Только хардкор, с закрытием периода, репликацией в OLAP, и пусть весь мир подождёт, пока мы перепишем всех клиентов.

Про эксперимент схемы — я всего лишь хотел посмотреть, какие индексы и как будут использоваться. Всё ещё жду схемы недоописанных таблиц.
V>Еще ты хотел посмотреть на движки работы с таблицами напрямую?
Да, было бы интересно. Всё ещё жду ссылки на клиентский интерфейс InnoDB или примеры кода, которые его употребляют.
V>И да, твои претензии к ISAM от непонимания, вестимо.
V>Тот же MS SQL — это банальный сервис над ISAM, т.е. непосредственный доступ к данным в данный момент времени имеет только одна программа.
(facepalm). Никакого ISAM в MS SQL Server нету и не было никогда. Коллега, не надо так позориться. Ну не знаешь ты, что такое ISAM — спроси, расскажем.
Претензии к нему у нас как раз от глубокого понимания ограничений этого метода хранения данных, по сравнению с page- и extent-based архитектурой.

	От:	Dym On
	Дата:	22.03.18 07:01
	Оценка:

	От:	Ночной Смотрящий
	Дата:	22.03.18 07:09
	Оценка:	-1

	От:	vdimas
	Дата:	22.03.18 10:29
	Оценка:

	От:	vdimas
	Дата:	22.03.18 10:30
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	22.03.18 11:53
Оценка:

	От:	Danchik
	Дата:	23.03.18 10:26
	Оценка:	3 (2)

	От:	LaPerouse
	Дата:	23.03.18 16:45
	Оценка: