Как выбрать СУБД ?

[Сергей Смирнов]

А вот раз пошла такая пьянка, скажите мне кто-нибудь, а есть ли в SQLDB какая-нибудь поддержка автоинкрементных полей?

Не помню за SQLDB, но в MSEgui уже все есть. Даже визуальный компонент. Это не причуда - он иногда незаменим.

Нет, целый компонент под это дело - уже, ИМХО, перебор

Сами виноваты - что бросили SQLDB на пол-пути. Чего и на кого теперь пенять ?

Бросили - поднимут Вообще, я не очень понимаю, чего там сейчас происходит. Похоже, Джуст куда-то делся, всё стоит колом.

А где они реагируют ? Ждут друг друга на лочке только пищущие транзакции.

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

[alexs]

Генерация отчетов с записью в БД обычно делается временные таблицы

Иногда заполнение временных таблиц обойдётся дороже чем пробежать по реальным данным
если же заполнять в свободное от основного вида деятельности время - теряется оперативность

Цитата:

в птице читающие транзакции ВОБЩЕ НИКАК не реагируеют на пишушие транзакции.



А где они реагируют ? Ждут друг друга на лочке только пищущие транзакции.

в блокировочной БД читающая транзакция будет ждать окончания процеса записи - MS не зря взяла код IB в MS2005 - версионник это класная вещь

[Brainenjii]

В птице тоже можно добиться блокировок таблиц, если нужно...

[debi12345]

в блокировочной БД читающая транзакция будет ждать окончания процеса записи - MS не зря взяла код IB в MS2005 - версионник это класная вещь

Не-а. Все зависит от заказанного режима блокировки.
Если нужна актуальность данных - заказываешь блокировку (ожидание освобождения LOCK ) чтения, не нужны последние данные - не заказываешь, а читаешь, что есть.

[alexs]

Не-а. Все зависит от заказанного режима блокировки.

не буду спорить - с блокировочными практически давно
не работал

В птице тоже можно добиться блокировок таблиц, если нужно...

но не нужно

[Brainenjii]

Ну, если каждая новая запись зависит от предыдущих - то нужно... По-крайней мере я не придумал, как отказаться от блокировок...

[alexs]

а транзакции зачем придумали? выполняеш последовательность действий в контексте одной транзакции и всё.

[Brainenjii]

Можно использовать одну транзакцию для нескольких пользователей ? 0.o
Но все-равно сложно... Это же придется перед каждым действием проверять - что сделали остальные...
Так, в общем, в базе хранится дерево, каждому элементу которого формируется код, описывающий положение элемента в этом самом дереве..., т.е. если есть элемент с кодом "а1", то первый дочерний его элемент будет иметь код "а1б1", а следующий - "а1б2"... И если будет не один изменять такое дерево, то придется мало того, что следить за индексами при литерах (таких уровней - с десяток у кажого справочника, т.е. 10*х генераторов создавать только под это), так еще и за структурой... Да и помимо кодов еще куча полей... В общем, горРаздо проще заблокировать таблицу на изменение, пока кто-то один не закончит полностью все изменения в нем ^_^

[alexs]

так и думал - что счётчики
т.е. фактически ты даёш оператром ввести значение а1б[2-3-4] (то что в скобках)? или просто при создании новой записи показываеш юзверю - что у него получится за код?

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

[Brainenjii]

Пока только видеть -даю, хотя да, действительно необязательно Хотя если не видеть - в гриде не видно будет, что дерево получается... А смотреть одновременно и на грид, и на тривью - неудобно... Но тут в другом проблема - если один, например, редактирует ветку, а другой её, скажем, удалит - это ведь тоже как-то централизовать придется... И опять же, даже если не показывать код опереторам - счетчики все-равно создавать придется... Зачем делать сотни генераторов, если можно обойтись несколькими блобами ? Хотя это и мелочь, в сравнении с управлением структурой... По логике не должны справочники эти часто меняться, и уж тем более - кучей народа... Так почему бы не дополнительно закрепить это блокировкой этих самых справочников на время изменений ^_^

[debi12345]

а транзакции зачем придумали? выполняеш последовательность действий в контексте одной транзакции и всё.

Да то же самое в птице, что и в других серверах. Просто в других даешь явную команду "LOCK режим", а в птичке для этого создается спец-транзакция, в настройках которой этот режим заказываешь. То есть птичники экономят на вызове LOCK, но создают объект-транзакцию. Один плюс этого компота вижу - не нужно вызывать ExecuteDirect('LOCK ...') перед активацией запроса.

[alexs]

И опять же, даже если не показывать код опереторам - счетчики все-равно создавать придется... Зачем делать сотни генераторов, если можно обойтись несколькими блобами ?

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

Да то же самое в птице, что и в других серверах. Просто в других даешь явную команду "LOCK режим", а в птичке для этого создается спец-транзакция, в настройках которой этот режим заказываешь. То есть птичники экономят на вызове LOCK, но создают объект-транзакцию

не - ты не понял вобще идеалогии
это специальная методика написания - чисто по предоставляемому функционалу птица не сильно отличается от остальных RDBMS - это специально так программы пишутся с использованием 2-х транзакций. ты точно также можеш писать, используя только 1 транзакцию, просто подверждая её после соханения данных и переоткрывая - но птица в таком случае использует больше ресурсов сервера и имеет меньшее быстродействие. а вот когда у тебя 2 транзакции (ты можеш эту методу использовать с любым языком прогр-я - транзакция это не объект) - то одна имеет право только читать - и она является не загружающей ресурсы сервера - все данные читаем через неё, а вот если нам надо что-либо изменить/добавить - то автоматом стартуется 2-я транзакция (пишущая) быстро выполняет изменения и потверждается(заершается) - далее работаем опять с только чтением.

[Brainenjii]

Какая разница - доп. таблица с парасчетчиками, или простро генераторы... Разве что таблица - почище, но помедленнее... И не понял, как значение не выпадает из диапазона - оператор взял значение из этой таблицы, увеличив его на 1 -> оператор отказался от сохранения -> значение уменьшается на 1, чтоли ? 0.o Так тогда вообще ужас будет с многопользовательским режимом ^_^ Вот у меня - действительно, есть возможность undo/redo, "берегущая" индексы, просто невозможная (ну или очень труднореализуемая) в условиях многопользовательности... ИМХО... Да и вообще, несколько раз акцентировал внимание, что как раз с этими "счетчиками" проблема значительно меньше, чем с сохранением структуры дерева... Для меня, по-крайней мере ^_^
P.S. кстати... Я вот не держу постоянно созданный Query... Т.е. когда требуется прочитать/записать данные в базу - создается Query, делает свое темное дело, и уничтожается... Это нормально, или очень плохо ? ^_^

[alexs]

взял значение из этой таблицы, увеличив его на 1 -> оператор отказался от сохранения -> значение уменьшается на 1, чтоли

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

Я вот не держу постоянно созданный Query... Т.е. когда требуется прочитать/записать данные в базу - создается Query, делает свое темное дело, и уничтожается...

для БД это даже лучше т.к. не задействуеш её ресурсы, если в клиентской морде нет утечек памяти - то очень хорошо

[debi12345]

P.S. кстати... Я вот не держу постоянно созданный Query... Т.е. когда требуется прочитать/записать данные в базу - создается Query, делает свое темное дело, и уничтожается... Это нормально, или очень плохо ? ^_^

К чему все эти хитрости, если уже давно все придумано ?
В Дельфях и MSEgui есть detached-режим работы выборок. Выбрал, сохранил в локальный файл (если надо), отключил соединение, завершил программу, вырубил компьютер, ушел домой, пришел утром, запустил программу, подгрузил сохраненные данные, поработал с ними локально, соединился с БД, записал изменения, отвалил, ...
Ессно, генерацию ключей и т.п нужно писать с учетом этого режима.