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

← →
Анонимщик © (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, то какой-нибудь другой макроязык.

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

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

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

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

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

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

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

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

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

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

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

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

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

Digitman

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

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

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

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

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

asp

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

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

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

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