Сообщение Re[39]: В России опять напишут новый объектно-ориентированны от 22.03.2018 10:29
Изменено 22.03.2018 10:35 vdimas
Re[39]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
V>>Это не таблица движений.
S>Это та самая таблица orders, которая обычно сидит в середине star join
Я хорошо знаю базу Northwind потому что, без ложной скромности, являюсь профи по MS Access. ))
Это не боевая система, в поделках такого уровня десятки таблиц максимум и все твои предыдущие аргументы теряют смысл, если подкреплять их подобными примерами. Тут мне опять не хватает смайлика на сравнимую величину твоейнеобъективности.
А как организованы настоящие боевые системы, где вообще имеет смысл рассуждать о размерности задач, я уже описывал.
Мы выше обсуждали таблицу движений, а она связана с таблицей ордеров по одному ровно индексу.
В боевой торговой системе примерно такой набор таблиц:
Тут 4 индекса, индекс {Document, Commodity} наиболее эффективно делать составным и кластерным.
Это таблица на оперемесяц для складского партионного учёта.
Для средневзвешенного учёта вместо Id партии товара указана себестоимость списания (за весь Amount, а не за единицу):
Тут 3 индекса.
Учёт по средневзвешенной цене более эфективный, если большой "проходняк" одних и тех же товаров.
Если много уникальных товаров, то удобнее партионный учёт.
Другие таблицы выглядят примерно так:
Основной join по классике master-slave — Documents->Movements.
Ну или два таких join по двум парам таблиц, если приход и расход живут в разных таблицах.
Для сильнонагруженных сценариев (приходы столь же часты как расходы) рекомендуется разделять таблицы прихода и расхода.
Если не разделять, то Amount и NetCost будут со знаком.
Для партионного учёта будет не один, а два join, если интересует не только кол-во, но и финансовая аналитика (нужна партия, в ней хранится цена прихода товара).
Хотя, это ХЗ. Если склад-бухгалтерия составляют одну систему, то по факту фиксации операции создаются соотв. проводки и финансовая аналитика чисто по складу вне бухгалтерии — это уже из разряда "в зубах поковыряться" или "репу почесать", т.е. такую аналитику уже удобней делать по историческим данным и OLAP.
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] Counterparties.Id
DocTypes
* Id
Name
TableName // не обязательно, эти "знания" могут содержатся в коде обслуживающей программы
Orders
* Id
CreationDate
* Author
Counterparty
...Основной join по классике master-slave — Documents->Movements.
Ну или два таких join по двум парам таблиц, если приход и расход живут в разных таблицах.
Для сильнонагруженных сценариев (приходы столь же часты как расходы) рекомендуется разделять таблицы прихода и расхода.
Если не разделять, то Amount и NetCost будут со знаком.
Для партионного учёта будет не один, а два join, если интересует не только кол-во, но и финансовая аналитика (нужна партия, в ней хранится цена прихода товара).
Хотя, это ХЗ. Если склад-бухгалтерия составляют одну систему, то по факту фиксации операции создаются соотв. проводки и финансовая аналитика чисто по складу вне бухгалтерии — это уже из разряда "в зубах поковыряться" или "репу почесать", т.е. такую аналитику уже удобней делать по историческим данным и OLAP.
Re[39]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
V>>Это не таблица движений.
S>Это та самая таблица orders, которая обычно сидит в середине star join
Я хорошо знаю базу Northwind потому что, без ложной скромности, являюсь профи по MS Access. ))
Это не боевая система, в поделках такого уровня десятки таблиц максимум и все твои предыдущие аргументы теряют смысл, если подкреплять их подобными примерами. Тут мне опять не хватает смайлика на сравнимую величину твоейнеобъективности.
А как организованы настоящие боевые системы, где вообще имеет смысл рассуждать о размерности задач, я уже описывал.
Мы выше обсуждали таблицу движений, а она связана с таблицей ордеров по одному ровно индексу.
В боевой торговой системе примерно такой набор таблиц:
Тут 4 индекса, индекс {Document, Commodity} наиболее эффективно делать составным и кластерным.
Это таблица на оперемесяц для складского партионного учёта.
Для средневзвешенного учёта вместо Id партии товара указана себестоимость списания (за весь Amount, а не за единицу):
Тут 3 индекса.
Учёт по средневзвешенной цене более эфективный, если большой "проходняк" одних и тех же товаров.
Если много уникальных товаров, то удобнее партионный учёт.
Другие таблицы выглядят примерно так:
Основной join по классике master-slave — Documents->Movements.
Ну или два таких join по двум парам таблиц, если приход и расход живут в разных таблицах.
Для сильнонагруженных сценариев (приходы столь же часты как расходы) рекомендуется разделять таблицы прихода и расхода.
Если не разделять, то Amount и NetCost будут со знаком.
Для партионного учёта будет не один, а два join, если интересует не только кол-во, но и финансовая аналитика (нужна партия, в ней хранится цена прихода товара).
Хотя, это ХЗ. Если склад-бухгалтерия составляют одну систему, то по факту фиксации операции создаются соотв. проводки и финансовая аналитика чисто по складу вне бухгалтерии — это уже из разряда "в зубах поковыряться" или "репу почесать", т.е. такую аналитику уже удобней делать по историческим данным и OLAP.
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.