![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Выбор БД [D2005, 2003]
crank © (2012-03-10 20:43:00)Помогите советом с выбором БД.
БД и оболочка к ней будут лежать на сервере. Пользователи (5 пользователй) работают в терминальном режиме.
Сейчас используется Access + оболочка для Delphi. Наткнулся на некоторое количество проблем связанных с обновлением данных: user1 добавил данные, но user2 их не увидит, пока не обновит таблицу. Можно ли это сделать как-то прозрачно? Понятно, что в Delphi однозначно придётся прописывать что-то вроде скрытого Refresh, но от "помощи" со стороны базы (если он возможен) не отказался бы
Добавляют примерно по 10-20 записей в день, т.е. нагрузка очень невелика
В отдалённом будущем хотелось бы связать имеющуюся БД с сайтом фирмы. Изначально планировал такую схему: на сервере стоит MySQL. На сайте прописано делать выборку из базы, хранящейся на сервере. Но сейчас засомневался в необходимости поднимать/устанавливать саму СУБД. В идеале хотелось бы хранения в одной папке и программы и файлов от базы данных... ну и возможности сайта обращаться к базе
bash77 (2012-03-15 14:46:00) [1]насколько я встрял в задачу (с первых 5 секунд)
я бы сделал:
1.база стопудово MySQL (т.к. одинаково прекрасно работает и под win и под nix) да и оболочек бесплатных клиентских хоть отбавляй.
2.насчет обновлений.... мож конект на сокет (тогда сервер писаный нужен)?
или может трех-звенная архитектрура ?? и че это я сказал (или повторился)... если это реально важно - я бы выбирал CORBA. но прошу учесть - я мог и не понять задачу, 5 суток подряд ложусь спать в 5 утра, и сижу уже работаю в 10
а про IB или FB ничего сказать не могу, не лежит у меня к ним душа, хоть и работаю с ними лет 8
crank (2012-03-13 20:39:00) [2]Благодарю :)
pavel_guzhanov (2012-03-13 09:33:00) [3]
> А можете показать простенький пример?
> Упорный
Ну раз такой упорный, то для INTERBASE или FIREBIRD:
Триггер в базе:
CREATE OR ALTER TRIGGER #ИМЯ_ТРИГГЕРА# FOR #ИМЯ_ТАБЛИЦЫ#
ACTIVE AFTER INSERT POSITION 0
AS
begin
POST_EVENT 'TABLE_CHANGED_14';
end
В программе добавляешь TIBEvents и в его событии EventAlert обрабатываешь полученное сообщение, например, выдаешь сообщение, что изменились данные в таблице и предложение обновить их.
crank (2012-03-12 20:47:00) [4]
> А User2 у нас кто.
Если это вопрос, то ответ в [14]
> User2 - подчинённый работник.
Anatoly Podgoretsky (2012-03-12 20:04:00) [5]А User2 у нас кто.
Секрет - тебе нужна трехзвенка.
crank (2012-03-12 18:32:00) [6]
> так понимаю тот самый "Манагер" это ты? очень уж сильная
> забота о... бывает только о себе любимом.
Нет... я отношусь к User2 :)
Всем спасибо за подсказки
Плохиш (2012-03-12 12:48:00) [7]
> В отдалённом будущем хотелось бы связать имеющуюся БД с
> сайтом фирмы. Изначально планировал такую схему: на сервере
> стоит MySQL. На сайте прописано делать выборку из базы,
> хранящейся на сервере. Но сейчас засомневался в необходимости
> поднимать/устанавливать саму СУБД. В идеале хотелось бы
> хранения в одной папке и программы и файлов от базы данных.
> .. ну и возможности сайта обращаться к базе
>
Веб-морде совершенно пофигу кого и кто там на сервере оповещает, пока она данные не попросит, она их и обрабатывать не будет. Т.ч. болтовня в этой ветке не имеет никакого смысла...
sniknik (2012-03-12 11:23:00) [8]> менеджер может подойти/позвонить работнику
или отправить письмо с подтверждением о прочтении.
> но если того нет на месте
то чем поможет "моментальное оповещение", там на далеком от него компьютере? а прийдя в чем проблема посмотреть не было ли чего?
> Манагер спокоен, что работа выполнена и можно сообщать клиенту
так понимаю тот самый "Манагер" это ты? очень уж сильная забота о... бывает только о себе любимом.
p.s. из личного опыта - ни одна задача поставленная чисто "манагером" без обработки техническим специалистом/с личным обсуждением "фейс ту фейс", не была выполнена...
а если какой проект и принимали от них "в чистом виде" то это выливалось в простую потерю времени.
Anatoly Podgoretsky (2012-03-12 11:05:00) [9]> crank (12.03.2012 10:34:14) [14]
Такие задачи решаются не с помощью базы, а специально созданого механизма
оповещения, база здесь совсем не нужна. Более того менеджер не узнает, что
работник увидел заявку, по твоим же словам - выезд к клиенту, подготовка
товара и т.п.
crank (2012-03-12 10:34:00) [10]
> начинать следует не этого, а с более раннего - нафига? нафига
> User2 знать что User1 добавил данные?
Допустим такую ситуацию: User1 - менеджер. Он принимает заявку на что-то там (выезд к клиенту, подготовка товара и т.п.)
User2 - подчинённый работник. Чем раньше он увидит, что поступила новая заявка, тем быстрее он её обработает
Конечно, менеджер может подойти/позвонить работнику, но если того нет на месте (обед, вызов, перекур, собирает товар на складе и.т.п), то манагеру придётся постоянно бегать и искать работника
После обработки заказа работник ставит галку в нужной записи. Манагер спокоен, что работа выполнена и можно сообщать клиенту
> Пользователь сам решит, когда ему обновлять интерфейс.
> И проклянет тебя если ты будешь ему мешать работать.
Снова скажете, что я упорный, но:
- обновление данных можно сделать опционально
- также обновление можно сделать недоступным при определённых условиях (пользователь редактирует данные)
Anatoly Podgoretsky (2012-03-12 10:02:00) [11]> crank (12.03.2012 09:55:11) [11]
Пользователь сам решит, когда ему обновлять интерфейс.
И проклянет тебя если ты будешь ему мешать работать.
Данное поведение правильно в большинстве приложений, есть некоторая
особенность в диспетчерских приложения, но там где данные не редактируются.
sniknik (2012-03-12 10:01:00) [12]> Как User2 узнает, что были добавлены данные?
начинать следует не этого, а с более раннего - нафига? нафига User2 знать что User1 добавил данные?
crank (2012-03-12 09:55:00) [13]
> а в тот момент когда она ему реально нужна ему ничего не
> стоит ее запросить, и сервер не откажет, ибо его основной
> смысл ждать подобных запросов.
Тогда подскажите примерную логику программы:
User1 добавляет данные
Как User2 узнает, что были добавлены данные? Посылать запрос каждые n-секунд?
По поводу модальности. Модальные окна не планируются (точнее их появление сведено к мнимому)
После упоминания о том, что в Firebird есть что-то подобное представлял себе, что при добавлении записей User'ом1 остальные увидят либо всплывашку, либо информацию в статусбаре о том, что добавлено столько-то новых записей
Anatoly Podgoretsky (2012-03-12 09:51:00) [14]Упорный
crank (2012-03-12 09:48:00) [15]
> Триггер на любые изменения, выдающий Event. Программа реагирует
> на этот Event.
А можете показать простенький пример? ^_^
sniknik (2012-03-12 09:46:00) [16]> сервер информирует клиента об обновлении
на кой клиенту информация, если она ему пофигу и ничего, он с ней делать не собирается?
мало того, в большинстве случаев он ее и получить то не сможет, ибо занят своими делами, блокирован вводом юзера/модальностью, а то и просто уже не работает...
а в тот момент когда она ему реально нужна ему ничего не стоит ее запросить, и сервер не откажет, ибо его основной смысл ждать подобных запросов.
crank (2012-03-12 09:40:00) [17]
> не дело это серверу командовать клиентом... он их обслуживает,
> выполняет их запросы, а не управляет.
Никто не говорит об управлении :) Имеется ввиду информирование... сервер информирует клиента об обновлении
sniknik (2012-03-12 08:05:00) [18]не дело это серверу командовать клиентом... он их обслуживает, выполняет их запросы, а не управляет.
через инет особенно... MySQL так сложилось делался под web... не думаю что там даже планировали подобное отступление от "классической логики клиент сервера", не то что делать...
crank (2012-03-12 06:55:00) [19]
>
> Да, это точно. Не всегда пользователь будет рад, если он
> работает с данными, и вдруг они взяли и обновились. Лучше
> все-таки сделать обновление данных по желанию пользователя.
>
Ну это само собой :)
>
> Рано или поздно все равно придешь к этому. Так что лучше
> сразу ставь.
А в MySQL тоже есть такие триггеры?
Jeer (2012-03-11 15:58:00) [20]Блокировка объекта (записи/ей), по другому - полный гемморой.