Добавить комментарий

Изображение пользователя st.

Разделение

[quote=norguhtar]Сейчас использование вместо bigint int это уже экономия на спичках. В любом случае система где будет работать база будет 64 битной и если это x86_64 ,то там int уже 64 бита, а не 32. Таким образом какого-то значительного выигрыша не получим. А вот когда у нас внезапно где-то произойдет упор в размерность ключа будет несколько грустно. Я в свое время кстати ловил такую проблему.[/quote]

Архитектура процессора и тип хранения не связаны. Тип int определяет 4 байта в файле на диске и только. Внутреннее представление в СУБД может быть совсем другим. Если по прикидкам получается "экономия на спичках" (т.е. размеры БД и индексов различаются на единицы процентов), то имеет смысл использовать последовательный UUID (который внутри int128). Это снимает все вопросы по синхронизации распределенной БД.

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

[quote=norguhtar]Давайте немного тут притормозим. Это не бухгалтерская система, как бы это странно не звучало. Это АСР. Основные ее пользователи это клиенты и обслуживающий персонал. По этой причине она не должна использовать учет по счетам. Учет по счетам возникнет, после выгрузки данных из АСР в бухгалтерию. Выгрузка есть всегда, так-как АСР охватывает только одну часть хозяйственной деятельности. А именно предоставление и учет услуг клиентам. Остальная часть хозяйственной деятельности в любом случае ведется в какой либо ERP системе.[/quote]

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