ОтчаянныйКак данная БД будет ворочаться, когда достигнет объемов больше 10Гб? Какие подводные камни возникают при таких объемах данных?Нормально она ворочается. У нас около 350 коннектов (по два на каждого юзера), база сейчас свыше 50 Гб (блобов очень мало). Кол-во транзакций в сутки - 1.1...1.3 млн (судя по логу последних дней).

Но вам обязательно придется:
1) настроить firebird.conf, т.к. по дефолту там настройки для запуска на P-III 350 MHz и работы 10 чел. Речь идёт прежде всего о DefaultDBCachePages, TempCacheLimit и, возможно, LockHashSlots.
2) освоить средство трассирования, дабы видеть тормозные запросы
3) мониторить базу на предмет застрявших OIT и отстреливать такие коннекты (в том числе пресловутый коннект от ИБЭ, когда "открыли таблицу и ушли домой")
4) не стесняться ходить сюда, на форум, и задавать глупые вопросы: ибо ФБ-разрабы тут очень частые гости и получите помощь из первых рук.

Подводный камень #1: размер страницы базы. Он должен быть не менее 8К. Если же юзаете таблицы с юникодом, то ставьте 16К, иначе непременно по индексам упрётесь в implementation limit exceeded.
Подводный камень #2: накопление мусора при "нечтении старых данных" (см. материал на ibase.ru) - обязательно по крону запускайте gfix -sweep. Если можете, лучше сразу добавьте в ХП, меняющие или удаляющие большие объёмы данных, повторную перечитку по только что выполненным критериям. Мусор должен собирать тот, кто насорил, а не тот, кто пришёл после.
Подводный камень #3: забывание отслежки новых сообщений в firebird.log. Базу ФБ развалить трудно, и обычно этому предшествуют сообщения в логе. На них обязательно обращайте внимание. К сож-ю, лог ФБ надо фильтровать: там будет еще и туча спама вида errno=-104 / -110 от некорректных отключек юзеров. :(

Dimitry SibiryakovТаблоидМусор должен собирать тот, кто насорил, а не тот, кто пришёл после.
Влад бы сказал "иногда лучше жевать..."Ну так кассирше со стоящим перед ней клиентом, коннект которой начал мусор собирать за каким-то поросёнком - ей что сказать ? Чтобы тоже жевала ? :-)

oleg_m тут Что именно "там" ? Про ту "же самую транзакцию" ?

DarkMasterкогда до 100Гб дорастет - перечитай пост Таблоида...нет, ему раньше придется, если эти 70 юзеров действительно что-то молотят, а не просто "сидят в программе".

Dimitry SibiryakovТаблоидПро ту "же самую транзакцию" ?
Ага. Откуда в "той же самой ХП" возьмётся мусор, годный к сборке.Найди, где я сказал про ТУ ЖЕ САМУЮ транзакцию.
Dimitry Sibiryakov[Собственно говоря, откуда вообще в данных, необходимых для работы АРМ кассирши может взяться мусор?..Если база спроектирована поклонниками EAV, то запросто.
И даже если не EAV, тоже: например, кассир при закрытии ("отгрузке") документа вызовет запись проводок, а обороты и остатки по счетам лежат там же, куда лезут бухи со своими корректировками.

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

WildSeryЧто именно "не айс"? То, что за них мусор будут те же бухгалтера собирать?Да, и не только бухи. Всякие начальнеги, клиент-менеджеры, логисты и проч. - им ведь тоже надоработать, а не на песочные часы глазеть. То, что коннект-поросёнок удалил / проапдейтил за день 100000 строк и дальше сказал: "ну я пошёл, а вы тут сами убирайтесь, на кого бог пошлёт" - это действительно выглядит как свинство с его стороны. Что в реале, что в виртуале :-)

Dimitry SibiryakovТаблоидНайди, где я сказал про ТУ ЖЕ САМУЮ транзакцию.А откуда в "той же самой ХП, меняющей или удаляющей большие объёмы данных" (про которую ты
сказал) возьмётся совсем другая транзакция?А что, "та же самая ХП" не может быть вызвана клиентом сразу после успешного коммита ? с теми же самыми параметрами + дополнительным параметром-флажком ("только прочитать") ?
Dimitry SibiryakovЭто с какого перепугу у вас кассир, "перед которым клиенты стоят" делает какую-то "отгрузку"?А по-твоему кто её должен делать ? Кто должен переводить изделия из регистра "Резерв" в регистр "Отгружено" ? Уж не склад ли, который заинтересован в списании с себя как можно большей недостачи ?

Ivan_PisarevskyТаблоидА по-твоему кто её должен делать ?реально бардак. Клиент принес на кассу товар, надо просто и быстро зафиксировать факт прохождения товара мимо кассы и получить оплату. Какие нахрен проводки? Какой мусор? Инсерт-инсерт-инсерт-принт. Хотя всякие скидочные-бонусные карты привносят гемору, тут возможны варианты.То, что именно бух. ПРОВОДКИ в этой проге пишутся КАССИРОМ - бред, разумеется. Но я не могу на это повлиять. Но ты процитировал фразу про ОТГРУЗКУ товара, про перевод его из одного регистра в другой. А это не проводки. Совсем.
> Хотя всякие скидочные-бонусные карты привносят гемору, тут возможны варианты.
И этого у нас тоже навалом. Задолбались с беск. хотелками начальства, связаннымис этими картами.
ладно, оффтоп уже давно идёт. И ты как админ должен бы уже передёрнуть свой затвор... :-)

Dimitry SibiryakovТаблоидА по-твоему кто её должен делать ? Кто должен переводить изделия из регистра "Резерв" в регистр "Отгружено" ?Тот, кто отгружает, вестимо.Это никогда не должен делать склад, который только и ждёт, чтобы сбагрить с себя то, что было стырено неизвестно кем и когда. И никакому манагеру склада, даже его супер-верховному-начальнику, нельзя давать такое право. Такова же, кстати, и политическая воля наших бызнес-водил.
Dimitry SibiryakovИ, кстати, какой-такой мусор может начать собирать update одной записи?..У нас помимо перевода изделий по регистрам надо еще FIFO-цепочки выстроить, т.е. с какого прихода списалось то или иное изделие. Сразу выстраивать их нельзя: просядет произв-сть на вводе в документ отдельных строк (АРМ менеджера: он часто не "руками" формирует док-т, а загружает список из заранее присланного файла). В общем, это ресурсоёмкая операция.
Ну так вот: когда формируются эти самые FIFO-цепочки, то там получается, что надо по диапазону искать. И мусор там непременно будет встречаться, ибо... EAV, чтоб её! У них и приходы и расходы и еще черт-те что - все в нескольких таблицах запихано

kdvгде даже по распиханным по нескольким таблицам данные собирались моментально.Почему "даже" ? Данные разной природы и надо распихивать по разным таблицам, чтобы как минимум спокойно установить на них нужные констрейнты (без опасения, что они затронут "не те" строки), да и трегеры тоже. А что касается быстрод-вия, то "много средних таблиц" по-любому лучще чем "одна большая". Индексы, как я тут выяснил недавно, очень не любят глубину >= 4

Dimitry Sibiryakovактивное подтверждение моего тезиса о кривизне рук в первом же ответе автору.ну, пущай почитает: на чужих ошибках тоже надо учиться :-)

тумак шампур,

это кому вопрос, мне или Ивану ?

WildSeryКаким местом тут отрицательные остатки, если клиент принёс номенклатуру на кассу?
Или в твоей кассе клиенту бы сказали "иди в ж..., у нас этого товара нет на складе"?Погодь... клиенту на руки никакой "номенклатуры" не отдают, пока он не оплатил. Он оплачивает документ, кассирша ставит ему на бумажку толкушку "Уплочено", прикалывает чек и он топает на окно выдачи.
Или у тебя не так ?

kdvТаблоидПогодь... клиенту на руки никакой "номенклатуры" не отдают, пока он не оплатил.клиент в магазине в тачку выбирает товар. Подходит к кассе.Это "не тот" магазин. Это ты про жратву говоришь :-)
А у нас тут запчасти всякие, дорогие как бэ... Витрины с мелочевкой - на замке, а что покрупнее (диски, например) - цепями или тросами примотаны. Ибо никому нельзя верить!

Ivan_PisarevskyВся движуха по резервированию идет на выписке продажником накладнушки.Ну, а по отгрузке кто "двигает" товар ? Вот был он зарезервирован, затем клиент оплатил - и ? Кто у тебя толкает этот товар в регистр "Отгружено" ?

Ivan_PisarevskyТаблоидКто у тебя толкает этот товар в регистр "Отгружено" ?Какая разница? клиент оплатил, товар ему отдан, дальше уже не жесткий реалтайм , пинай хоть справа-налево, хоть слева-направо.Жёсткий. Ибо в эту же минуту может позвонить следующий клиент и продавец, увидев, что товар есть, но за кем-то *зарезервирован*, полезет разбираться, что за резерв, нельзя ли снять его и т.п. И даже если снять уже нельзя (ввиду закрытия соотв. документа) - он время потеряет на этом выяснении.

Ivan_PisarevskyТаблоидно за кем-то *зарезервирован*У вас резерв не резерв а нечто необязательное?Зависит от:
1) давности резерва (слишком старые отменяются автоматом)
2) под кого зарезервировали
3) кто, наоборот, сейчас запрашивает изделие, которое имеется только в резерве. Если запрашивает VIP, а по пункту "2)" резервировал частник, то там могут и отменить резерв этого частника.

Dimitry SibiryakovТаблоидЖёсткий.
А чего он жёсткий-то? Ответил этому клиенту "товара нет" сразу, а потом выясняй хоть до
морковкина заговня действительно товара нет или кто-то просто забыл резервацию снять. Во
втором случае товар просто будет продан следующему человеку, который позвонит через час.Не, так дело не пойдёть :-)
Во-первых, склад крайне заинтересован в максимальном уровне продаж, от этого их зарплата зависит;
Во-вторых, следующий чел за этой же деталькой может позвонить через месяц, или еще позже;
В-третьих, есть такое понятие как "уровень сервиса": отношение числа свершивхися продаж (т.е. строк в документах в состоянии "Отгружено") к общему числу запросов. Оно должно быть не меньше 0.75...0.8 - иначе будут на нас "нехорошо глядеть" из представительств заводов-изготовителей а/м.
Так что надо непременно стараться впарить :-)

Dimitry SibiryakovТаблоидсейчас запрашивает изделие, которое имеется только в резерве. Если
запрашивает VIP, а по пункту "2)" резервировал частник, то там могут и отменить резерв
этого частника.Т.е. частника, который товар уже оплатил, забрал и из магазина вышел, догонят, товар отберут, а труп сбросят в речку?..Ни один частник (и юрик тоже) не выйдет живым из нашего Самого Правильного магазина с товаром без чека
То есть, с документом, подтверждающим отгрузку ему этого товара, что ТОЖДЕСТВЕННО списанию этого же товара с регистра резерва.