Розничный магазин. На кассах стоят компы, на каждой своя база (только для набивания чеков). Есть еще общая база в которой ведется учет. понадобилось написать систему начисления и оплаты покупки бонусами. Вот теперь думаю - где хранить остаток по бонусным карточкам? Лепить еще одну базу карточек в sql и писать прямые запросы из каждой базы? Подскажите как такое лучше реализовать.

(0) "на каждой своя база"
В этих базах "как-то" номенклатура обновляется?
ИМХО, вариант: грузить "одновременно с номенклатурой" данные по бонусным картам.

Начнем с того, 1с ли, и если да - конфы и релиз

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

(1) проблема в том, что остаток бонусов на карточке нужен во всех кассовых базах. т.е. если перекидывать с касс в основную движения по ним, то потом надо будет на каждую закидывать остатки по ним. как-то много движений.

к примеру, такой случай. покупатель рассчитывается бонусами под ноль, выходит, заходит и рассчитывается на другой кассе.

(5) Центральная база и кассовые базы территориально в одном месте?

>> Лепить еще одну базу карточек в sql и писать прямые запросы из каждой базы? Подскажите как такое лучше реализовать.

Отдельную базу 1С с нужным функционалом. Обращаться через OLE.

(6) в одной локальной сетке.

Внешняя база sql.
И типа как то так.
Соединение = СоздатьОбъект("ADODB.Connection");
АДОДБ_УстановитьСоединение(Соединение);
Команда = СоздатьОбъект("ADODB.Command");
Команда.ActiveConnection=Соединение;

(7) OLE глючное.

(7)+ или в ней "...общая база в которой ведется учет..."

(10) Плохому танцору ...

(9) т.е. всё-таки прямыми запросами? sql 2000 подойдет ?

А почему не хотят сделать единую базу?

(12) да нет. писал я под OLE. хреново ошибки отлавливать. чуть что и зависла в памяти.

(14) на кассах будет тупить.

(14) а так на кассах база из одного справочника и одного документа.

Проверяем карту если в sql есть заводим на кассе новую. Начисляем или списываем бонус, удаляем. Всё!

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

(18) т.е. начислили - прописали в sql движение, списали - прописали в sql движение.

(19) sql не проще будет? просто я прямыми запросами никогда не пользовался. думаю, может есть какой-то вариант попроще.

Работает не первый год.

(22) прямыми запросами?

(21) Прошу прощения не до конца прочитал вашу ситуацию. У нас все точки не в одной локальной сети естественно. В вашем случаи хз, скорость что Sql что веб сервиса примерно одинаковая, но первый вариант несколько проще.

1с++?

Там 3 момента 1: получить баланс 2: начислить бонус 3: списать бонус. В пределах одного региона у разных провайдеров с статичным ip проблем нет. 1с++ нет.

(26) у меня всё в локалке. а где почитать про прямые запросы?

1cpp.ru/forum

ок. буду курить форум. спасибо.

(16) скока их?

(28) +1 и все в ваших руках

(0) Все зависит от того что вы там за систему бонусов напридумывали. Вариантов, как вы понимаете (надеюсь), очень много. Соответственно и решений вопроса может быть несколько.
Да, придется делать БД в скуле в которой и хранить данные по бонусам. Опять таки - что хранить, зависит от того что вы напридумывали. БД синхронизировать средствами СУБД через определенное время. Недостатки отсутствия связи думаю сами понимаете ...

как вариант он-лайн: основная база слушает tcp порт, а кассы (при наличии связи) получают и пишут что надо в осн.базу. если нет связи, то сделать очередь и при появлении только дописывать бонусы.

по работе 1с с tcp/ip куча инфы (есть и внешн. компоненты: RiK_Inet, NetaInet и т.д.).

(30) две.

(32) главный вопрос где хранить остатки по бонусам. как их начислять - это отдельный вопрос (тариф "простой", логарифмическая линейка для расчета остатка в подарок:). хранить нужно номер карты и движения по ним с привязкой к номеру чека.

(33) стабильно работает?

(35) Ну тогда ответ я вам дал. Берите тот же экспресс от мелкомягких и делайте БД. Там по сути пара-тройка таблиц будет, если все так как вы сказали.

(36) Это будет зависить от стабильности самой 1С. если осн. база перестанет "слушать" порт - то увы, но это проверяется любыми системами контроля. Либо если сетка глючная.

По организации структуры бд: можно в 1с-ии, можно на стороних бд - это уже зависит от фантазии разраба... но, как я думаю, поддерживать проше ту систему, которая более однородна, а не состоит из кучи разномастных костылей. если управляющая 1С - то проше остальное, по возможности, прикручивать от 1С и средствами 1С, если 1с сильно тупит - то 1с++.

(38) ну и в продолжения огр.структуры (по своему опыту):
если допил одноразовый "на сейчас" то проще в стороней бд, если на перспективу, долгосрочный или периодически будет использоваться  - то в 1с.

А что будет когда у вас появится второй магазин?

(35) а почему экспресс? просто основная база на 2000-м крутится.

(40) навряд ли. скорее эти закроются :)

(41) Вероятно потому что вы изначально указали что кассы работают каждая со своей базой. Бред конечно, но это ваш вазелин - мне не жалко.
Соответственно на том же экспрессе наваять пару-тройку табличек будет быстрее. Плюс синхронизация на уровне СУБД. Плюс все легально. Плюс ...

(43) если бы всё было в одной базе - было бы проще. но отказоустойчивость бы сильно пострадала. а так сервер отрубился - кассы работают. сеть упала - кассы работают. плюс скорость работы в одной базе значительно бы упала. насколько я знаю, крупные сети так и поступают: на каждой кассе своя база, синхронизация с основной по расписанию . а вот бонусы надо чтоб сразу синхронизировались.

мне было бы проще писать через ОЛЕ. примерно такой алгоритм:
1. при запуске базы на кассе, подключение к общей базе через ОЛЕ.
2. при оплате или начислении бонуса - проведение в общей базе движения по карточке с привязкой к номеру чека.
3. обработка ошибок: если ошибка в ОЛЕ (нету связи, не удалось провести документ), запись в константу факта сбоя, начисление бонусов оставить, списывать не давать.
4. при повторном открытии читаем константу, если был сбой - перепроверяем что провели по бонусам в общей базе ( за сегодня).
ну как-то так. попахивает каким-то колхозом :)

(45)+ хотя лучше не общую, а в отдельную. а так смысл тот же.

(44-46) Это не колхозом попахивает, а отсутствием опыта. Касательно (44) - у нормальных людей бек и фронт разделены. И разделены не по причине нагрузки на сервер, а как раз по причине обеспечить автономную работу в случае форс-мажора. Там простой выйдет дороже чем потратиться на обеспечение бесперебойной работы.
Что касается вас - я предложил вариант. Ну а вам уже решать - подходит или нет.

P.S.
Если это 1 торговая точка то я б все вел в одной скульной базе и незаморачивался.