Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > MS SQL Server > Совместный доступ к данным в MS SQL

Автор: TwoK 24.5.2002, 09:32

Вторую неделю штудирую все, что найду по MS SQL. Версия седьмая + билдер (читай - дельфи), если что. Но вот чего не могу понять:

Судя по всему, нотификаций о добавлении / изменении / удалении при таком подходе нет. Тогда как быть? Каждую секунду кверить базу? Но это ж елы-палы, какой трафик поднимется.. Vit, ты как-то когда речь об этом шла, сказал, что у тебя на сервере пролетает 50 кверей в секунду - и никакого трафика. То есть - есть механизм отслежевания, какой клиент чего "недополучил", я так понимаю? И _каждому_ клиенту пойдут не записи, а указания, что добавить, что изменить и что удалить?

Да и с интерфейсом надо что-то делать. Например, disable кнопку "Изменить" или "Удалить", если запись занята.

Автор: Vit 24.5.2002, 15:29

Нет, так не пойдет. Вообще логика другая... Ты не должен и не можешь отслеживать изменения (это можно делать с помощью Live Query но категорически не рекомендуется). Это не локальные данные и эксклюзивного открытия таблиц быть по идее не должно. Мои тебе советы:

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

Когда ты работал в Парадоксе или чем то подобном, тебе было это необходимо по причине практической невозможности транзакций, ты открывал курсор и редактировал данные, при этом все остальные не могли в это время делать изменения - курсор "держал" таблицу. В MS SQL Server , так же как и во всех серверах данных, ты НЕ ДОЛЖЕН НАКЛАДЫВАТЬ КУРСОР(хотя и можешь), иначе вся система будет жутко тормозить. Например пользователь запросил данные - ты запускаешь select забираешь данные, показываешь их пользователю, он их изменил - ты формируешь Insert, Delete или Update Query и отсылаешь на сервер. Работы в реальном времени - когда ты видишь на экране именно то что на сервере в данный момент нет и быть не может - этого даже сам Enterprise Manager для SQL Server не поддерживает. Я могу объяснить почему - например офис в котором сидит 50 человек и что-то делают с базами - каждую секунду таблица меняется несколько раз, в таком случае просто физически НЕТ никакого алгоритма показывать все в real-time, даже если придумать очень хитрый механизм передачи только изменений - никто не гарантирует что изменения коснуться только 1 поля или записи - я могу тебе такой Update наворотить, что в твоей таблице ничего от старой не останется, а в это время кто-то сделал "Select * ".

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

Автор: Vit 24.5.2002, 15:33

Цитата(TwoK @ 24.5.2002, 01:32)

Тогда как быть? Каждую секунду кверить базу? Но это ж елы-палы, какой трафик поднимется..

Знаешь, ты реально проверь, такой ли уж трафик. Я вначале тоже пугался - на парадоксе открывал курсор, делал Update нескольких полей и нескольких рекордов, а перешел на SQL пришлось вместо казалось, бы одной операции делать десяток Update кверей - и ты знаешь ничего... Вообще квери которые затрагивают 1 запись идут очень быстро (если медленно - значит неправильно установленны индексы) - несколько сот в секунду с одной машины...

Автор: TwoK 24.5.2002, 16:29

Цитата

изменение интерфейса и логики отражающие внутреннюю логику работы

Ну я врубился, что основам принципов построения баз в моей голове придется делать DELETE

. А потом INSERT...

Цитата

Если честно, мне-то по барабну, будет там трафик или нет. Просто люди иногда еще по сети файлами обмениваются... а если я кверить раз в секунду буду ну пусть с 10 мест - SQL мне все забъет что можно хоть там 100 мегабит, хоть гиг...

Давай я тут попробую посчитать, а ты мне скажешь. где я не прав.

Ну к примеру. Одна таблица. Чисто на данные одной записи идет килобайт. Тысяча записей - метр. Пропускная сети ну пусть 10 метров в секунду. Пока один - нормал. Десять человек - и все, тупик.

Конечно, ставить таймер на 1 сек и все перекверивать - нереально. То есть нерационально. Потому как не требуется. Но вот в плане целостности... Как выход, конечно, перекверить все _именно_ перед добавлением / изменением/удалением, чтобы исключить проблемы с удалением удаленного...

Как тебе мои подсчеты?

ЗЫ. Не читал случайно на Королевстве Дельфи статейку на тему "как грохнуть без восстановления всю базу" двумя нажатиями клавиш?

Автор: Vit 24.5.2002, 17:50

Цитата

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

Ну это совсем другое дело, к счастью чтобы предотвратить ситуацию когда ты например делаешь Insert, а уже кто-то создал запись и надо делать Update можно, и нужно это делать в одной транзакции, т.е. в ADO кверю пишешь например следующий код:

Код


DECLARE @NameId Varchar (6)
DECLARE @Email Varchar (100)
DECLARE @recNum int

SET @NameId = :NameId
SET @Email = :Email

IF NOT ((@NameId IS NULL) or (@EMAIL IS NULL))
  begin
    SELECT @RecNum = count(*) FROM Emails
    WHERE ((NameId = @NameId) and (Email = @Email))

    IF @RecNum = 0
      begin
        INSERT INTO Emails
               (NameId,   Email, MyAnotherField)
        VALUES (@NameId, @Email, :MyAnotherField)
      end
    else
      begin
        Update INTO Emails
        Set MyAnotherField = :MyAnotherField
        Where (NameId=@NameId) and (Email=@Email)
      end
  end

Объясняю - в таблицу надо занести значение MyAnotherField для определенного NameId и Email. Вначале проверяется на то что параметры передались правильные, затем смотрится есть ли записи для NameId и Email, если есть то делается Update, если нет то вставляется новая запись.

Все что начинается с @ - переменные
Все что начинается с : - параметры, их можно передать из программы примерно так:

ADOQuery1.parameters.parambyname('Email'

.value:='nevzorov@yahoo.com';

Автор: Vit 24.5.2002, 17:53

Цитата

Ну к примеру. Одна таблица. Чисто на данные одной записи идет килобайт. Тысяча записей - метр. Пропускная сети ну пусть 10 метров в секунду. Пока один - нормал. Десять человек - и все, тупик.

Вот поэтому такой ситуации быть не должно вообще - ты никогда (разве что только для репортов), не должен вытягивать из базы больше десятка записей, причем не целиком а только те поля которые тебе нужны и все будет путем

Автор: Vit 28.5.2002, 22:25

Цитата(TwoK @ 24.5.2002, 08:29)

ЗЫ. Не читал случайно на Королевстве Дельфи статейку на тему "как грохнуть без восстановления всю базу" двумя нажатиями клавиш?

Нет, не читал, но способы знаю.

1) Делаешь кверю "Truncate Table MyTableName" на всех таблицах - идет мгновенно, в транз.лог не пишет, так что восстановление невозможно.

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

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

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

5) Делаешь такую же базу данных(но чистую) на другом сервере, и меняешь их IP адреса местами, теперь все компы будут видеть новый сервер вместо старого под тем же именем (если конечно ты используешь доступ через TCP/IP)

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