• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

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

    Запись на курс до 25 апреля. Получить промодоступ ...

7.7 Количество Документов И Быстродействие

  • Автор темы olga13
  • Дата начала
O

olga13

Добрый день! Хочу обратиться за советом к старшим товарищам. Предприятие планирует открытие розничного магазина. Ожидаемое количество покупок в день - около 500. Стоит дилемма: создавать документ на каждый чек, либо объединять проданный товар в конце дня в сводном чеке. В последнем случае сходные позиции будут группироваться, что соответственно приведет к уменьшению проводок в базе, но создаст определенные неудобства в работе. Каково ваше мнение, что лучше: много маленьких документов или один большой? Меня пугают, что при использовании первого варианта со временем база разрастется до невероятных размеров и станет тормозить. Так ли это на самом деле?
 
T

tadancer

База файловая или sql? Типовая? Регистры или плансчетов?
В чем необходимость хранить все чеки - возвраты?

Объедините оба варианта. На каждый чек отдельный документ, старые (допустим, со сроком больше N месяцев, в зависимости от того чем торгует магазин, для продуктов - меньше, для бытовой техники - гораздо больше), или же в зависимости от того, в течение какого срока требуется информация о каждой отдельной продаже, чеки сворачиваются в одиночный документ "продажа за день" с теми же проводками/движениями что и каждый чек по-отдельности, сами чеки - удаляются.
 
O

olga13

База файловая или sql? Типовая? Регистры или плансчетов?
В чем необходимость хранить все чеки - возвраты?

Объедините оба варианта. На каждый чек отдельный документ, старые (допустим, со сроком больше N месяцев, в зависимости от того чем торгует магазин, для продуктов - меньше, для бытовой техники - гораздо больше), или же в зависимости от того, в течение какого срока требуется информация о каждой отдельной продаже, чеки сворачиваются в одиночный документ "продажа за день" с теми же проводками/движениями что и каждый чек по-отдельности, сами чеки - удаляются.

База DBF, не типовая, бухгалтерия + регистры.
Меня интересует, есть ли смысл вообще сворачивать в один документ. Если отбросить тот факт, что в сводном чеке одинаковые позиции свернутся, будет ли вообще в чем-то разница? Мне кажется, что размер индексных файлов от этого не изменится.
 
T

tadancer

У файловой 7ки 2 ограничителя:
1) размер файлов .dbf (каждого по отдельности)
2) количество записей в файлах .dbf (аналогично)

Размер: больше гигабайта = возможны проблемы, больше 2 гигабайт - база перестает работать.
Количество записей, если ничего не путаю, около миллиарда, потом опять же проблемы с работой.

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

olga13

У файловой 7ки 2 ограничителя:
1) размер файлов .dbf (каждого по отдельности)
2) количество записей в файлах .dbf (аналогично)

Размер: больше гигабайта = возможны проблемы, больше 2 гигабайт - база перестает работать.
Количество записей, если ничего не путаю, около миллиарда, потом опять же проблемы с работой.

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


Спасибо за совет. Наверное, так и поступлю.
 
E

evgenyatam

сами чеки - удаляются.

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

Обучение наступательной кибербезопасности в игровой форме. Начать игру!