Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
В общем, есть у нас 250 торговых точек в 86 городах Сейчас разрабатываем свой софт из-за своих особенностей уходим от другим программ. В день идет примерно 10 000 заказов, в базе порядка 100 наименований товаров для каждой точки. Собственно вопрос в том, как лучше реализовать таблицу для хранения операций ? так как база очень быстро станет большой и как все будет работать когда там будет 10 млн записей и все увеличиваться ? Основные щас проблемы, как считать остатки на складе грамотно при такой большой загруженности, склад на каждый точке и таблица операций на кассе Если у кого есть практические примеры построение бд для склада, поделитесь пожалуйста ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2018, 19:08 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
amxserv, использовать партицирование ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2018, 19:17 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
amxservв 86 городахВ таких условиях я бы стал думать прежде всего об архитектуре всего этого распределения. Тут явно одним экземпляром СУБД не обойтись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2018, 19:33 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
авторОсновные щас проблемы, как считать остатки на складе грамотно при такой большой загруженности, считать остатки на конец дня и суммировать к ним приходы/расходы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2018, 21:16 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
amxservВ день идет примерно 10 000 заказовЕсли даже допустить по 10 позиций на заказ - 100к позиций. Ссылка на товар - 8 байт. Количество - 8 байт. SynPK - 8 байт. Плюс накладные расходы. 3 метра в день. Плюс индексы. Плюс фрагментация и коэфф. заполнения. 10-12 метров в день, 4 гига в год. Тьфу, и растереть. amxservкак считать остатки на складе грамотно при такой большой загруженностиИ все через Инет лезут в одну и ту же БД? да ладно... небось у каждого своя копия (ну в лучшем случае копия на пару соседних городов). Но даже если все в одной базе - 8 секунд на заказ... большая загруженность? amxservкак считать остатки на складе грамотноВ статический срез - ежесуточно. Ну или хотя бы ежемесячно. Имея срез на начало месяца, операции после среза и вменяемые индексы, получить текущий баланс по складу - не бином Ньютона уж точно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2018, 22:08 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
miksoftamxservв 86 городахВ таких условиях я бы стал думать прежде всего об архитектуре всего этого распределения. Тут явно одним экземпляром СУБД не обойтись. Неизвестно что будет лучше/хуже. Организовывать удаленный доступ к центральной базе или делать синхронизация/обмен с кучей локальных. Всё зависит от размеров этих самых "торговых точек". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 02:58 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
Ну есть же давно отработанные схемы: Таблица документов Таблица строк документов Таблица номенклатуры. Таблица картотеки Регистры с остатками и триггера для их расчета и контроля. Вы хотите изобрести что-то новое? Какая проблема "Считать остатки"? Вы что пересчитываете их каждый раз? Не храните "текущие остатки"? Как долго делается отчет "остатки по всем складам по всей номенклатуре"? Как часто вы "считаете остатки"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 03:26 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
amxservВ день идет примерно 10 000 заказов, в базе порядка 100 наименований товаров для каждой точки. + перемещения + закуп +списание. Получится 4-5 млн документов в год. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 03:43 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
И до 500 млн строк документов. Объемы солидные, но вполне обсчитываемые. При условии ежегодичного "закрытия" БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 03:45 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
982183Неизвестно что будет лучше/хуже. Организовывать удаленный доступ к центральной базе или делать синхронизация/обмен с кучей локальных. Всё зависит от размеров этих самых "торговых точек".Да вроде бы "всё украдено уже до вас"... основа в облаке и работа через веб-интерфейс. При неустойчивом доступе - локальная копия, оффлайн-операции с синхронизацией при наличии/восстановлении связи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 07:16 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
Ну да, последние лет 5-10 большинство так и делают. Хотя остались уникумы с локальными независимыми базами с периодическим импортом/экспортом буфера документов. Зачастую (в рознице) в центральной базе не нужны все дневные документы реализации, а достаточно дневного сводного реестра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 07:30 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
982183Зачастую (в рознице) в центральной базе не нужны все дневные документы реализации, а достаточно дневного сводного реестра.Ооо... это до первой проверки. К тому же выгрузка всего массива "на базу" - это дополнительный бэкап, которого мало не бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 07:36 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
А "проверка" как на это влияет? Никаким законам это не противоречит. С магазина в центральный офис идет за день один документ в виде сводной накладной реализации. Там же Приходы/списание/пересортица. Явно это займет меньше времени и ресурсов, чем онлайн синхронизация базы. или выгрузка каждой покупки в отдельной накладной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 07:41 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
982183Зачастую (в рознице) в центральной базе не нужны все дневные документы реализацииЗависит от учетной политики организации. При товарно-суммовой - достаточно, но, сколь я помню, налоговая очень косо на нее смотрит. В общем варианты с точки зрения бизнеса бывают разные. Поэтому сначала нужно собрать эти требования, а уж потом проектировать. А не сразу за таблички хвататься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 08:00 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
При "товарно-суммовом" мы передаем только сумму реализации за день. Я же говорил о дилемме "передавать данные о каждой продаже" или "передавать сводную накладную реализации" В "сводной накладной" есть весь список проданных за день товаров с суммой реализации по каждому товару. Иногда её делают в разрезе касс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 08:13 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
982183Никаким законам это не противоречит.Угу... вот только всякоразны проверяющие могут и как люди, а могут и все жилы выдрать - и всё будет ведь в рамках закона...miksoftналоговая очень косо на нее смотритА аудит, особенно свой, но внешний, так и просто без детализации разговаривать не станет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 08:18 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
Akina982183Никаким законам это не противоречит.Угу... вот только всякоразны проверяющие могут и как люди, а могут и все жилы выдрать - и всё будет ведь в рамках закона...miksoftналоговая очень косо на нее смотритА аудит, особенно свой, но внешний, так и просто без детализации разговаривать не станет. Всякоразные проверяющий всё равно туда не полезут, а потребуют некие сводные/агрегированные отчеты. А если и встанет вопрос по конкретному чеку, то есть БД магазина, откуда всё это можно вытащить. А основная задача - не перегружать учетную систему ненужными ей детализациями. Несомненно - не везде это работает. Но при разделении уровней доступа/детализации - Бухгалтерия/логистика/розница Вполне реально относительно дешево создать работоспособную систему на достаточно больших объемах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 08:38 |
|
||
|
Как хранить в mysql большую таблицу операций?
|
|||
|---|---|---|---|
|
#18+
Делайте закрытие периода. В таблицу регистров заносите остатки на начало периода. Все записи сбрасываете в архив (копия таблицы регистров). К архиву текущие операции не обращаются, пусть растет себе в размерах. Будет мешать - скинете еще куда-нибудь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 09:43 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39651477&tid=1829825]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 377ms |

| 0 / 0 |
