On Wed, 31 Oct 2007 20:37:41 +0300, Konstantin R. Beliaev [EMAIL PROTECTED]
wrote:
Да вот, нифига:
1 номенклатура * 50 складов = +50 строк в таблице _в_день_.
Т.е. за месяц такая табличка прирастает на 15 млн записей.
А вы говорите объем не важен...
Мнэээ. А зачем дублировать сами
Кроме того, такое линейное складирование крайне излишне - достаточно
хранить историю изменения остатков.
история изменения остатков - это что? собственно таблица бухпроводок или
после проведения каждого документа в отдельную табличку инсертится
строка с новыми остатками?
Я собственно
Кроме того, такое линейное складирование крайне излишне - достаточно
хранить историю изменения остатков.
история изменения остатков - это что? собственно таблица бухпроводок или
после проведения каждого документа в отдельную табличку инсертится строка
с новыми остатками?
On Thu, 01 Nov 2007 10:27:09 +0300, Vladimir Kozlov [EMAIL PROTECTED] wrote:
история изменения остатков - это что? собственно таблица бухпроводок или
после проведения каждого документа в отдельную табличку инсертится строка с
новыми остатками?
Для подсчёта изменений товарного остатка и
старым. И есть процедурка - получить текущий остаток. Соответственно
она
как на счет многопользовательской работы?
смотрит - есть запись в таблице текущих остатков - достать оттуда
в ее транзакции - нету, а параллельной - есть дальше продолжать?
Хм. Ну если уж на то пошло - то и
Помню, смотрел когда-то телефонный справочник на FoxPro 2.6, года
2000-го, что-ли... Там умельцы 6-значный номер упаковывали в 3 знака... И шо
оно им дало, кроме гемороя при распаковке?
Вобщем, очередная экономия на тактах процессора...
On Thu, 01 Nov 2007 13:54:24 +0300, Андрій Жук [EMAIL PROTECTED] wrote:
Там умельцы 6-значный номер упаковывали в 3 знака...
Мнэээ.
Печатные символы только допускались? А то вроде как в 2^24 целых 7 знаков
влазит, и особого геморроя при распаковке не наблюдается...
--
Сергей Смирнов.
Отводим каждому дню по биту, и вуаля - объем хранимых данных сокращается
в 30 раз! Можно пойти еще дальше - если все 12 месяцев запихнуть в одну
строку в БД, то получается по одной строке на каждый товар в год.
Использование блобов позволит не ограничиваться одним годом.
PS: ;-)
WildSery wrote:
Да пусть с ним, с объёмом. Винты нонче дешёвые.
Главное, скорость не увеличится. Зато геморроя добавится. А вот это уже
печально.
Да вот, нифига:
1 номенклатура * 50 складов = +50 строк в таблице _в_день_.
Т.е. за месяц такая табличка прирастает на 15 млн записей.
А
Нужно узнать наличие чего-то, например, товара на складе, в определенный
день. Интересует именно был/не был, а не количество.
В месяце 28..31 день. На наше счастье, в integer 32 бита (как удачно-то
:-) ).
Отводим каждому дню по биту, и вуаля - объем хранимых данных сокращается
в 30 раз! Можно
Привет!
Нужно узнать наличие чего-то, например, товара на складе, в определенный
день. Интересует именно был/не был, а не количество.
В месяце 28..31 день. На наше счастье, в integer 32 бита (как удачно-то
:-) ).
Некузяво юзать массивы в реляционной СУБД. :)
--
Best regards,
Sergey
Можно пойти еще дальше - если все 12 месяцев запихнуть в одну
строку в БД, то получается по одной строке на каждый товар в год.
Извлекать данные, конечно будет нетривиально, зато сильно экономим на
поиске в таблице (особенно если номенклатура в несколько сот тысяч).
Можно пойти еще дальше -
On Tue, 30 Oct 2007 19:09:56 +0300, Konstantin R. Beliaev [EMAIL PROTECTED]
wrote:
вуаля - объем хранимых данных сокращается в 30 раз!
Да пусть с ним, с объёмом. Винты нонче дешёвые.
Главное, скорость не увеличится. Зато геморроя добавится. А вот это уже
печально.
--
Сергей Смирнов.
13 matches
Mail list logo
