Работа с БД в оперативной памяти

← →
georgeted (2010-05-23 20:47) [0]

Господа. Облазил полгугла но так и не нашел решения для своей проблемы... А проблема такая. У меня есть программа, работающая с некими таблицами, содержимое которых должно быть защищено от чужих рук. Программа однопользовательская (без применения серверов БД) и желательно без установки на пользовательский компьютер дополнительного софта. На сегодняшний день используется компоненты TSqlMemTable, однако они не устраивают меня из-за огроменного размера БД (20000 записей = 150Мб), хотя это не так критично. Самое печальное что они очень долго грузятся. Вот такая табличка сжирает 300мб оперативки, что не есть весело. Другое решение - использование компонентов Absolute DB, они создают файл БД защищенный паролем (можно выбрать алгоритм шифрования), но размер БД тоже большой (если в 1м варианте можно было перегонять базу в архиве, то во 2м уже так не получится - плохо жмется).
Да, еще одно. Для работы используется SQL, так что ClientDataSet и иже подобные ему не сгодятся... Есть ли у кого какие мысли как лучше сделать?

← →
Sergey13 © (2010-05-24 09:01) [1]

> [0] georgeted (23.05.10 20:47)
> Другое решение - использование компонентов Absolute DB,
> они создают файл БД защищенный паролем (можно выбрать алгоритм
> шифрования), но размер БД тоже большой

И не влезают на дискету?

Ну положи базу на флешку: нет флешки - нет базы.

Любая секретная информация легко извлекается с помощью или шоколадки или паяльника.

← →
Anatoly Podgoretsky © (2010-05-24 09:07) [2]

> georgeted (23.05.2010 20:47:00) [0]

А ты чего хочешь, при смене размер БД врядли изменится, поскольку это размер
данных, а у тебя 7.5 кб на запись, это немного.
Теперь насчет оперативки, так у тебя же InMemoryDataset и естественно все в
памяти, хочешь меньше, отказывася от InMemoryDataset

← →
georgeted (2010-05-24 09:18) [3]

Не я не про то чтобы БД была размером в 20кб, но ведь есть ведь разумные пределы... 10000 записей и БД в 200 метров ИМХО это перебор... Потом. Sergey13 не впадай в крайности. Почему вы считаете что моя цель - запихать БД на дискету? Ее будут качать из инета а на безлиме (среди возможных пользователей программы) будут сидеть мягко говоря не все. Чем меньше - тем лучше. Опять-таки в разумных пределах. Будет весить 10 метров - оч хорошо. Надеюсь в архиве будет еще меньше... 10000 записей это много разве? Вот сколько по-вашему такая таблица должна занимать места в оперативке и на диске?

← →
georgeted (2010-05-24 09:22) [4]

Да, и про метод защиты базы - я не хочу сделать супер-пупер мега защиту от пентагона, чтоб ее не брал крутой зуб мега хацкера.. Не паролить же БД Аксеса... Шифрование содержимого в таблицах - один из вариантов, но я решил оставить этот вариант на "потом", если не найду другого решения.

← →
Sergey13 © (2010-05-24 09:35) [5]

> [3] georgeted (24.05.10 09:18)

Откуда я знаю что у тебя за записи? Может это собрание фильмов со всего мира.
В любом случае - надо разбираться конкретно. А ты - размер файла большой, значит не подходит. Может там например надо бекап/рестор сделать просто и файл ужмется. Я с Абсолютом не работал, но по отзывам неплохая штука, поэтому вряд ли там место расходуется просто так.

← →
sniknik © (2010-05-24 09:46) [6]

> А ты чего хочешь, при смене размер БД врядли изменится, поскольку это размер
> данных, а у тебя 7.5 кб на запись, это немного.
ну как же, смена на базу с юникодом без сжатия увеличит запись а значит и ее в ~2 раза (это если сейчас не юникод), смена типов полей с char на varchar уменьшит на неопределенное число байт (может движок уже не поддерживает или эмулирует char), а значит и всю базу ... ну в общем понятно.

> но ведь есть ведь разумные пределы... 10000 записей и БД в 200 метров ИМХО это перебор...
> (20000 записей = 150Мб)
очевидно половина это 75 мб на диске, возможно в сжатом виде. разожми, добавь структуры обработки, выровняй по границам чтобы была возможна прямая индексация, т.е. подготовь к работе и ... 200 мб это абсолютно нормально. (во всяком случае не удивительно)

> Не паролить же БД Аксеса...
а почему нет? если
> я не хочу сделать супер-пупер мега защиту от пентагона, чтоб ее не брал крутой зуб мега хацкера..
и юзерам "защиты" хватает, и админам не мешает.

> Шифрование содержимого в таблицах - один из вариантов
усиленно не рекомендую, если есть в планах поддержка проги.

← →
Anatoly Podgoretsky © (2010-05-24 11:06) [7]

> Не я не про то чтобы БД была размером в 20кб, но ведь есть
> ведь разумные пределы... 10000 записей и БД в 200 метров
> ИМХО это перебор... Потом. Sergey13 не

Странная у тебя база при 20 000 записей занимает 150 мб, а при 10 000 уже 200 мб.

← →
Anatoly Podgoretsky © (2010-05-24 11:08) [8]

> Вот сколько по-вашему такая таблица должна занимать места
> в оперативке и на диске?

Вопрос абсурдный сам по себе.

← →
georgeted (2010-05-24 12:07) [9]

Блин. Я говорю примерные цифры, что вы придираетесь? Хорошо. Почему таблица из 8ми полей (2 поля int и 6 полей varchar(50)) при 20000 записях весит ПРИМЕРНО 150-200 Мб а в архиве 2.5Мб? Чудо-зип? Если же эту таблицу хранить в Аксесе то она занимает не более 5ти метров. В Абсолюте размер увеличивается до 50-70Мб. Я то изначально спрашивал знаете ли вы что получше или нет? А вы сразу зачмырили...

По-поводу защиты. Программа ориентирована на широкий круг пользователей и я точно знаю что парочка организаций попробует мою базу на зуб. Поэтому и озабочен ее защитой.

← →
sniknik © (2010-05-24 12:44) [10]

> В Абсолюте размер увеличивается до 50-70Мб.
они насколько помню и с dbf работали... может "тяжелое наследие прошлого"... тип varchar определяется именно типом, а по хранению аналогичен char как в dbf.

> Если же эту таблицу хранить в Аксесе то она занимает не более 5ти метров.
сжатие... но если поработать, и "раздуть" рабочие области то при тех же данных можешь получить базу в 300 мг (а можно и больше, парочку гетерогенных запросов сделать когда все ко всему, и готово вместо 5ти мегабайт 1 гигабайт...).

> и я точно знаю что парочка организаций попробует мою базу на зуб.
прикинь как удивятся если дать в открытом виде...

> Поэтому и озабочен ее защитой.
от кого? от тех для кого пишешь? а подумай как им с ней работать/поддерживать. вот сказала твоя чудо прога "ошибка в данных" и повисла... и после перезагрузки повисла только запустившись с той же ошибкой, и посмотреть в чем дело никак. скажешь невозможно?

← →
Anatoly Podgoretsky © (2010-05-24 12:50) [11]

> georgeted (24.05.2010 12:07:09) [9]

Насчет придирок - придирка только с твоей стороны, а ты люди технические и
уважаем точность!

Обычный zip, почему бы ему не сжимать до такой степени, если данные
позволяют, а тебе что шашечки или ехать?

Храни в Акцессе или не жалуйся.

И про гугл не ври, гугл это свыше 500 000 компьютеров, не точно его половину, но и один процент невозможно облазить.

и я точно знаю что парочка организаций попробует мою базу на зуб. Поэтому и озабочен ее защитой.

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

> Медвежонок Пятачок (24.05.2010 13:05:13) [13]

Неуловимый Джо!

← →
georgeted (2010-05-27 21:25) [15]

Удалено модератором
Примечание: Не надо наездов на отвечающих

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

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

Работа с БД в оперативной памяти Найти похожие ветки