Движок базы данных

← →
Анонимщик (2004-02-02 17:19) [0]

Кто подскажет движок базы данных, который бы позвоялял:
1. Хранить все данные в памяти.
2. Имел бы триггеры и хранимые процедуры.
3. Давал возможность накладывать первичные/вторичные индексы.
4. Не был блокировочником.
5. Позволял бы многопользовательский доступ, причем один экземпляр для чтения и записи, остальные - только для чтения.

← →
MV (2004-02-02 17:29) [1]

С требованием

1. Хранить все данные в памяти

- никакой.

Вариант: Delphi.

← →
HSolo (2004-02-02 17:45) [2]

IB / FB / Yaffil

← →
MV (2004-02-02 17:46) [3]

IB / FB / Yaffil
...в памяти?

← →
Анонимщик (2004-02-02 17:49) [4]

Я же сказал: в памяти и не блокировочник

← →
sniknik (2004-02-02 17:51) [5]

в памяти?
> 2. Имел бы триггеры и хранимые процедуры.
????

> 5. Позволял бы многопользовательский доступ, причем один экземпляр для чтения и записи, остальные - только для чтения.
?????????

нет таких.

← →
Анонимщик (2004-02-02 17:53) [6]

Ладно, хранимые процедуры убираем, вместо триггеров достаточно автоинкрементных полей, даже и их не нужно, если что.

← →
HSolo (2004-02-02 17:54) [7]

А что Вы понимаете под "в памяти" ?

← →
MV (2004-02-02 17:57) [8]

2. Имел бы триггеры и хранимые процедуры.
3. Давал возможность накладывать первичные/вторичные индексы.
4. Не был блокировочником.

- и халявный - FireBird.

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

- насчет экземпляров - это как?

← →
sniknik (2004-02-02 17:58) [9]

а многопользовательский доступ? оставляем?

хотя если подумать, мидас это для вас. ;о) + клиент/ADO датасет (позволяют рекордсеты в памяти)
все примочки от sql сервера делаем руками.

← →
Анонимщик (2004-02-02 17:59) [10]

Чтоб на диск не писалось, вот и все, лишние тормоза не нужны.
Ориентировочно: три таблицы, около 200 000 - 500 000 записей, общий объем - до 10-ти мегабайт (самих таблиц, без индексирования).
Никаких отметок на удаление, удаляться записи должны сразу; не знаю, есть ли смысл говорить о транзакциях в моем случае, но, если есть, то чтоб их не было.

← →
Анонимщик (2004-02-02 18:02) [11]

И не версионник само собой

← →
MV (2004-02-02 18:02) [12]

10 мегабайт делим на 500 000 записей = 20 байт на запись

Класс.

А если 10 мегабайт в сумме на все три таблицы - то по 6 байт на таблицу.

Супер.

← →
Анонимщик (2004-02-02 18:08) [13]

MV
Насчет экземпляров - прошу прощения, грубо выразился, я имел в виду экземпляры соединения с БД.
10 мегабайт на 200 000 записей = 50 байт на запись, мне хватает.
Одна из таблиц - большая, в остальных - записей чуть-чуть.
Хватит прикалываться, не знаем - молчим.

sniknik
Midas - пробовал, тормоза после 100 000 записей.
Примочки руками - не могу, это долго, я зашьюсь в конце концов, да и, мне кажется, овчинка выделки не стоит, должно уже что-то такое быть.

← →
MV (2004-02-02 18:21) [14]

Джулиан Бакнелл. "Фундаментальные алгоритмы и структуры данных в Дельфи". Расписано все с примерами.
Создаем динамические массивы с индексами, триггеры реализуем на как функции доступа к свойствам. Связи, доступ и все остальное тоже ручками. Без SQL. Хотя если проблема, чтобы на диск не писалось (типа очень секретно) - не поможет все равно. Виндовс сама решает, кого и когда свопить. Так что FireBird. Создаем виртуальный диск, на нем генерим базу, и дальше - как обычно.
FireBird из перечисленного (кроме 1) может все.

← →
Анонимщик (2004-02-02 18:29) [15]

1. Нет ничего секретного.
2. Ручками - проблема; зачем огород городить на том, что должно быть написано и без меня. Поменяю завтра структуру - переписывать? Кроме того, динамических массивов будет недостаточно, нужны будут еще двоичные деревья, связные списки, возможно, и, возможно, хеш-таблицы и прочая хрень. Впрочем, ладно, не вам ведь писать, оно и советовать вроде проще.
3. Не FireBird, мне не нужен версионник, это точно.

Так что ответа нет.
Ладно, спасибо и на том.

← →
MV (2004-02-02 18:31) [16]

Анонимщик © (02.02.04 17:19)
4. Не был блокировочником.

Анонимщик © (02.02.04 18:29) [15]
3. Не FireBird, мне не нужен версионник, это точно.

Класс.
Удачи!

← →
Anatoly Podgoretsky (2004-02-02 20:12) [17]

MV (02.02.04 18:31) [16]
Промежуточник

← →
Sergey_Masloff (2004-02-02 20:32) [18]

Анонимщик © (02.02.04 18:29) [15]
>2. Ручками - проблема;
ну это мы поняли
>зачем огород городить на том, что должно быть написано и без >меня. Поменяю завтра структуру - переписывать? Кроме того, >динамических массивов будет недостаточно, нужны будут еще >двоичные деревья, связные списки, возможно, и, возможно, хеш->таблицы и прочая хрень. Впрочем, ладно, не вам ведь писать, оно >и советовать вроде проще.
отмазки не катят

>3. Не FireBird, мне не нужен версионник, это точно.
Знаешь еще способы кроме версионников и блокировочников?

>Так что ответа нет.
Ответ есть. Если бы ты так не пыжился то нашел бы его давно и не парил людям мозги. Твою проблему решит практически любой сервер СУБД, уж ORACLE и MSSQL точно, я думаю и в FB уже убрали излишнюю экономию оперативки. При наличии достаточного объема памяти ВСЕ данные будут сидеть в кеше. АБСОЛЮТНО никакого оверхеда связанного с записью на диск в данном случае не будет.

>Я же сказал: в памяти и не блокировочник
ты можешь говорить что угодно. Все эти разговоры происходят из незнания предмета. Точка.

← →
Deniz (2004-02-03 09:57) [19]

В орешник :)

← →
Анонимщик (2004-02-03 10:59) [20]

Знаешь еще способы кроме версионников и блокировочников?

Знаю.

← →
Digitman (2004-02-03 11:05) [21]

> Анонимщик © (03.02.04 10:59) [20]

> Знаю.

просвети уж нас, тундру беспросветную, о секретном третьем варианте ?

← →
Анонимщик (2004-02-03 11:12) [22]

Открой любой файл для редактирования и подумай - файловая система его блокирует или версионит.

← →
Sandman25 (2004-02-03 11:16) [23]

В общем, Анонимщику нужна СУБД без транзакций. Кто последний записал, тот и молодец.

← →
Анонимщик (2004-02-03 11:21) [24]

Я сказал ведь, один пишет - остальные только читают. О транзакциях тоже было. Какие еще вопросы? От вас всегда нужно отбиваться?

← →
Sandman25 (2004-02-03 11:24) [25]

[24] Анонимщик © (03.02.04 11:21)

Это называется, подходит блокировочник с возможностью отключения блокировки (dirty read).

← →
Digitman (2004-02-03 11:33) [26]

> Анонимщик © (03.02.04 11:12) [22]

и какое же определение ты сам даешь механизму работы файловой системы ? и почему не упоминаешь, какую ФС имеешь ввиду ? NTFS действует по иному нежели FAT - ее работа в ряде ситуаций сродни версионнику ..

← →
Romkin (2004-02-03 11:34) [27]

Тебе не нужна СУБД. Небольшой сервер, со списками или другими структурами. Thread safe. Без SQL, увы, придется обойтись :)

← →
Анонимщик (2004-02-03 11:50) [28]

Sandman25
Ну, это не то чтоб совсем dirty read, но, скажем так, поскольку транзакций нет, то и подтверждать нечего. Впрочем, если настаиваешь, что это именно грязное чтение, то по смыслу - да.

Digitman
А что это, мы уже все-таки начали обсуждать? Зачем это - в орешник и все дела.

Romkin
Согласен, что СУБД здесь, может и не нужна. Но! Во-первых, в другую ветку такие вопросы задавать, вроде, не стоит. Во-вторых, мне-то, скорее всего, придется структуру переделывать и экспериментировать. Хотя, конечно, идеальный вариант - библиотека с указанными тобой функциями. И где оно, да чтоб удобство было? В этом и вопрос, собственно. А что касается SQL - то это, может, и необязательно, но лучше бы было, если не SQL, то какой-нибудь другой макроязык.

← →
asp (2004-02-03 11:52) [29]

Анонимщик © (03.02.04 11:21) [24]> Ввиду нестандартности придется.
Каверзный вопрос по поводу отсутствия транзакций: а если пользователь, наложивший блокировку аварийно вывалится?
IMHO, критерий незаписи на диск совершенно напрасен. Как уже писали, СУБД поддерживают кэширование таблиц.

← →
Boroda Oleg (2004-02-03 11:54) [30]

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

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

← →
Digitman (2004-02-03 11:59) [31]

> Анонимщик © (02.02.04 17:59) [10]
> Чтоб на диск не писалось, вот и все

а про свопинг забыл ? система без твоего ведома примет решение, выкинуть ли редко используемые страницы ВАП в файл подкачки или не трогать до поры до времени ...

это ты как бы к дисковым операциям не относишь уже ? я правильно понимаю ?

← →
asp (2004-02-03 12:08) [32]

В продолжение темы.
В DB2, например, можно отключить своппинг NT дабы не получить двойной. Плюс своп можно разместить на неформатированную партицию, избавляясь от расходов на файловую систему.
Т. е. используя СУБД, даже в случае своппинга можно добиться лучших результатов. IMHO.

← →
Danilka (2004-02-03 12:16) [33]

[32] asp © (03.02.04 12:08)
СУБД никак низя, ибо есть каприз - шоб обязательно не блокировочник и не версионник, и на винт писать тоже ничего низя ни в коем случае.

И пока автор ветки не объяснит, что за задача под такие бредовые условия, это останется всего-лишь капризом.
Вероятно, есть такие задачи, но я не могу себе их представить.

← →
Анонимщик (2004-02-03 12:16) [34]

asp
а если пользователь, наложивший блокировку аварийно вывалится?

На самом деле все подключения - из одной программы. Так что ничего страшного.

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

Digitman

Ни о чем я не забыл. Но требования более-менее гибкие. И, надеюсь, при гигабайте памяти 10 мегабайт не засвопятся никогда. Но это отдельный вопрос, конечно.

← →
Анонимщик (2004-02-03 12:18) [35]

Короче говоря, быстренько отвечаем о библиотеке.
Нет ответов - нет вопроса.
Если все, то всем спасибо.

← →
Sandman25 (2004-02-03 12:19) [36]

но мне нужно 50-100 обновлений в секунду

О каких обновлениях речь? Обновление грида на экране?

← →
Анонимщик (2004-02-03 12:22) [37]

Sandman25
Я еще с ума не сошел.
Обновлений записей в одной из таблиц.

← →
asp (2004-02-03 12:24) [38]

← →
Анонимщик (2004-02-03 12:27) [39]

asp

Не, оно такие объемы не тянет, проверено. Кроме того, ключи медленные. И потом, запросы не быстрые. Все из-за неоптимальных, видимо, алгоритмов поиска данных. То же самое на двоичных деревьях работате как нужно, но, как уже говорил, устану под каждый конкретный случай структуры городить.

← →
Digitman (2004-02-03 12:28) [40]

> Анонимщик © (03.02.04 12:18) [35]

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

← →
Анонимщик (2004-02-03 12:32) [41]

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

← →
Romkin (2004-02-03 12:45) [42]

TMultiReadSingleWriteSyncronizer + TList (TThreadList)

← →
Sir Alex (2004-02-03 12:46) [43]

>Анонимщик © (03.02.04 12:32) [41]

Посмотри:
- Absolute Database
- kbmMemTable (кажись так)
- Apollo VCL

Что-нить да подойдет...

← →
Анонимщик (2004-02-03 12:49) [44]

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

Sir Alex
Спасибо, щас.

← →
Анонимщик (2004-02-03 12:53) [45]

Sir Alex
А сам не использовал? Впечатления можно услышать?

← →
Digitman (2004-02-03 13:04) [46]

> Анонимщик © (03.02.04 12:53) [45]

есть еще одно простейшее решение : реализуешь MIDAS-сервер, который будет монопольно работать с каким-нибудь готовым TMemoryTable, предоставлять через IAppServer интерфейс DataSetProvider"а и с пом. TMultiReadSingleWriteSyncronizer осуществлять нужный тебе арбитраж мультипоточных обращений к НД

доступ к твоему MIDAS-серверу сос стороны клиентских процессов осуществляешь обычным образом - через MidasConnection и ClientDataSet

← →
Sir Alex (2004-02-03 13:21) [47]

2 Анонимщик © (03.02.04 12:53) [45]
В твоем случае больше всего подходит AbsDatabase, у него и SQL и in-memry tables и еще куча всего...
Не пробовал (т.е. не использовал в реальных проектах).

- kbm - Пробовал 2 года назад, непонравилась работа с фильтрами (если установить фильтр, то нельзя узнать сколько записей БД, и у пользователя в гриде скроллбар становился 3-state(3-и положения), что меня крайне удивило и я ее снес). Как она сейчас работает я не знаю.

- Apollo VCL - работает на основе DBF(FoxPro,Clipper, HiPerSix), использовал, если надо делать работу с DBF. требует наличие отдельных DLL.

← →
Анонимщик (2004-02-03 14:33) [48]

Sir Alex
Спасибо большое, буду проверять.

← →
Анонимщик (2004-02-03 14:34) [49]

Извини, а какой вариант лучше использовать:

Personal Edition
Single-User Edition
Multi-User Edition

Движок базы данных Найти похожие ветки