Посоветуйте, пожалуйста, с помощью какой СУБД проще организовать ведение базы пользователей/покупателей собственного софта.

Структура записи примитивная — имя/фамилия, email, сведения о лицензиях (если есть), произвольные заметки (особенности использования программ, субъективные впечатления и т.п.).

Необходимо наличие командно-строкового интерфейса для добавления, поиска и удаления записей под Windows/Linux, чтобы прикрутить к скриптам.

Под винду очень желательно наличие хотя бы простенького гуя для просмотра базы, формирования запросов по типовым критериям и т.п.

Было бы неплохо наличие сжатия на лету, а также частичной/полной синхронизации (например, порция записей в течение дня или недели накапливается на сервере, а затем разом добавляется к полной базе, которая лежит у меня на рабочей станции).

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

Я в современных СУБД совершенно не ориентируюсь, знаю только названия вроде MySQL, SqLite, Access и т.п.

P.S. Забыл указать, что максимальный объем базы — не больше сотни тысяч записей, так что "серьезных" решений не требуется.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Посоветуйте, пожалуйста, с помощью какой СУБД проще организовать ведение базы пользователей/покупателей собственного софта.

ЕМ>Структура записи примитивная — имя/фамилия, email, сведения о лицензиях (если есть), произвольные заметки (особенности использования программ, субъективные впечатления и т.п.).

sqlite

ЕМ>Необходимо наличие командно-строкового интерфейса для добавления, поиска и удаления записей под Windows/Linux, чтобы прикрутить к скриптам.

+

ЕМ>Под винду очень желательно наличие хотя бы простенького гуя для просмотра базы, формирования запросов по типовым критериям и т.п.

sqlitespy

ЕМ>Было бы неплохо наличие сжатия на лету, а также частичной/полной синхронизации (например, порция записей в течение дня или недели накапливается на сервере, а затем разом добавляется к полной базе, которая лежит у меня на рабочей станции).

—

ЕМ>Еще хотелось бы поддержки шифрования, чтобы на сервере держать только открытый ключ, по которому шифровались бы поступающие в базу данные, а секретный ключ использовался бы только на рабочей станции.

хз

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Посоветуйте, пожалуйста, с помощью какой СУБД проще организовать ведение базы пользователей/покупателей собственного софта.

В принципе с помощью любой. Самый простой вариант это sqlite.

ЕМ>Структура записи примитивная — имя/фамилия, email, сведения о лицензиях (если есть), произвольные заметки (особенности использования программ, субъективные впечатления и т.п.).

Любая база может.

ЕМ>Необходимо наличие командно-строкового интерфейса для добавления, поиска и удаления записей под Windows/Linux, чтобы прикрутить к скриптам.

Любая база может.

ЕМ>Под винду очень желательно наличие хотя бы простенького гуя для просмотра базы, формирования запросов по типовым критериям и т.п.

Тут точно не подскажу, но клиентов для любых БД десятки, думаю, найти можно что-нибудь по вкусу.

ЕМ>Было бы неплохо наличие сжатия на лету

Вроде есть, хотя не знаю, зачем тебе это на таких объёмах.

EM>а также частичной/полной синхронизации (например, порция записей в течение дня или недели накапливается на сервере, а затем разом добавляется к полной базе, которая лежит у меня на рабочей станции).

Это, скорей всего, придётся делать самому, хотя по описанию несложно, один скрипт выгружает новые и изменённые записи, второй скрипт вставляет или редактирует другую базу. Но проще всего просто копировать сами файлы базы. Можно с помощью инструмента вроде rsync, он будет копировать только изменённые байты, а не пересылать весь файл.

ЕМ>Еще хотелось бы поддержки шифрования, чтобы на сервере держать только открытый ключ, по которому шифровались бы поступающие в базу данные, а секретный ключ использовался бы только на рабочей станции.

Вот этого я нигде не видел. Просто пароль на базу — видел, а именно с ключами не видел. Подозреваю, что это технически невозможно, т.к. базе требуется доступ к содержимому полей для запросов и тд. Я бы секретную часть хранил в отдельном поле в виде бинарных данных и шифровал бы в приложении, работающем с БД.

ЕМ>Я в современных СУБД совершенно не ориентируюсь, знаю только названия вроде MySQL, SqLite, Access и т.п.

SQLite это очень простая, но очень проверенная и вполне полноценная для своего класса база. У неё нет сервера, это встраиваемая база (т.е. работает как DLL), вся база лежит в одном файле. Один минус: если требуется параллельный доступ нескольких приложений к одной базе, тут SQLite не параллелится, работать они будут по очереди.

Postgres это полноценная клиент-серверная СУБД. Если нужна "взрослая" БД, тебе сюда. Поддерживает любые объёмы, любые нагрузки.

MySQL неплохая база, но зачем она нужна при живом постгресе, я не знаю. Раньше она была совсем плохая, сейчас вроде получше стала.

Коммерческие базы при живом постгресе тоже не вижу смысла смотреть.

В общем резюмируя, SQLite тебе подойдёт почти идеально (за вычетом шифрования).

Здравствуйте, vsb, Вы писали:

vsb> неё нет сервера, это встраиваемая база (т.е. работает как DLL)
Добавлю еще что есть консольное приложение, через которое с ней можно работать. ТС это вроде важно.

vsb>В общем резюмируя, SQLite тебе подойдёт почти идеально (за вычетом шифрования).

Но если очень хочется, то есть расширения для SQLite добавляющие в нее шифрование. Не пользовался, но слышал.
Так же в свое время удивился, узнав что обычный дотнетный провайдер к нему (который System.Data.SQLite), уже из коробки поддерживает шифрование. Правда, опробовать шифрование на деле так и не довелось.

Здравствуйте, fmiracle, Вы писали:

vsb>> неё нет сервера, это встраиваемая база (т.е. работает как DLL)
F>Добавлю еще что есть консольное приложение, через которое с ней можно работать. ТС это вроде важно.

Ну консольный клиент есть вообще у любой базы. Как её администрировать-то без него.

vsb>>В общем резюмируя, SQLite тебе подойдёт почти идеально (за вычетом шифрования).

F>Но если очень хочется, то есть расширения для SQLite добавляющие в нее шифрование. Не пользовался, но слышал.

Насколько я знаю, это симметричное шифрование (то бишь при открытии базы надо передать пароль). Честно говоря довольно бесполезная штука на мой взгляд. Сложно представить модель угрозы, при которой это имеет смысл.

Здравствуйте, vsb, Вы писали:

ЕМ>>Было бы неплохо наличие сжатия на лету

vsb>Вроде есть, хотя не знаю, зачем тебе это на таких объёмах.

Да есть мысль запихивать туда все, что присылают регистраторы — иногда требуется для идентификации пользователя, чтоб не лазить к регистратору в список заказов. Но еще не решил, хочу ли.

ЕМ>>Еще хотелось бы поддержки шифрования, чтобы на сервере держать только открытый ключ, по которому шифровались бы поступающие в базу данные

vsb>Подозреваю, что это технически невозможно, т.к. базе требуется доступ к содержимому полей для запросов и тд.

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

vsb>Я бы секретную часть хранил в отдельном поле в виде бинарных данных и шифровал бы в приложении, работающем с БД.

А я как раз пытаюсь минимизировать объем работы по реализации.

vsb>В общем резюмируя, SQLite тебе подойдёт почти идеально (за вычетом шифрования).

Складывается впечатление, что так. Тем лучше, спасибо!

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Посоветуйте, пожалуйста, с помощью какой СУБД проще организовать ведение базы пользователей/покупателей собственного софта.

Как человек измученный нарзаном, посоветую держать эту базу сразу на web сервере и делать у ней простенькую web-морду на PHP.

У меня база на MySQL (больше 10 лет).

Сейчас бы я делал на PG. Тут можно размахнуться со структурой БД (MySQL её не тянет), бо у меня опыт в этом деле есть.

Firebird не советую, потому что единственный нормальный драйвер делаю я, а он у меня под Windows

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Как человек измученный нарзаном, посоветую держать эту базу сразу на web сервере и делать у ней простенькую web-морду на PHP.

Как-то чересчур радикально. Из каких соображений именно так?

КД>Сейчас бы я делал на PG. Тут можно размахнуться со структурой БД (MySQL её не тянет)

Что за структура, если не секрет?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Посоветуйте, пожалуйста, с помощью какой СУБД проще организовать ведение базы пользователей/покупателей собственного софта.

1с, разумеется )))
И покупатели будут, и расчёты, и счета выставлять....

Здравствуйте, Евгений Музыченко, Вы писали:

КД>>Как человек измученный нарзаном, посоветую держать эту базу сразу на web сервере и делать у ней простенькую web-морду на PHP.

ЕМ>Как-то чересчур радикально. Из каких соображений именно так?

Скажу так. Сначала у нас была локальная база (2005-2008). Мы с ней намудохались и с 2008 у нас база на web-сервере.

У неё две морды — для администраторов и для клиентов.

КД>>Сейчас бы я делал на PG. Тут можно размахнуться со структурой БД (MySQL её не тянет)

ЕМ>Что за структура, если не секрет?

Отображение объектов на реляционную модель. Я тут как-то про неё писал

Автор: Коваленко Дмитрий
Дата: 04.04.03

.

Типа COM, но для реляционной БД.

1) Сначала на ней обслуживался алкогольный склад (1998-не знаю до каких они с ней игрались). Сейчас о нем остались только воспоминания: раз и два. На IB5.

2) Потом на ней сидел центр регистрации сделок с недвижимостью Липецкой области (2002-2008). Тут было все во взрослому. На Firebird.

3) Пару лет назад, партнер (имеющий представление о п2) увлекался криптой и попросил спроектировать ему нормальную базу под это дело. Проект не поехал, но болванку базы (на PG) и небольшую обвязку на PHP я ему сделал. Дабы добро не пропадало зря — выгрузил на github.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Сейчас бы я делал на PG. Тут можно размахнуться со структурой БД (MySQL её не тянет), бо у меня опыт в этом деле есть.

А можно подробнее, что не тянет?

Как уже писали, базу можно взять любую, но sqlite все держит в одном файле, который можно просто скопировать, например к себе на ноут и иметь всю базу с собой (только ничего в ней не менять, потому что изменения сами в другую копию не попадут). В качестве GUI для начала достаточно взять любую софтину для разработки и управления базами — dbeaver, например (бесплатно и с нужной функциональностью разберешься довольно быстро).

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Посоветуйте, пожалуйста, с помощью какой СУБД проще организовать ведение базы пользователей/покупателей собственного софта.

https://www.h2database.com/html/main.html

Здравствуйте, Sharov, Вы писали:


КД>>Сейчас бы я делал на PG. Тут можно размахнуться со структурой БД (MySQL её не тянет), бо у меня опыт в этом деле есть.

S>А можно подробнее, что не тянет?

Сервер должен поддерживать "одновременное" удаление двух связанных записей.

Rec1<-Rec2

При удалении Rec1 отрабатывает FK с каскадным удалением, который удаляет Rec2.

При удалении Rec2 отрабатывает триггер на удаление, который удаляет Rec1.

--
На MySQL такое организовать не удалось — вылазила ошибка.

Если я правильно помню, проблемы с триггером.

Здравствуйте, varenikAA, Вы писали:

AA>Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>Посоветуйте, пожалуйста, с помощью какой СУБД проще организовать ведение базы пользователей/покупателей собственного софта.

AA>https://www.h2database.com/html/main.html

Это не продакшн вообще ни разу. Тесты только пускать можно на ней.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Сначала у нас была локальная база (2005-2008). Мы с ней намудохались и с 2008 у нас база на web-сервере.
КД>У неё две морды — для администраторов и для клиентов.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Посоветуйте, пожалуйста, с помощью какой СУБД проще организовать ведение базы пользователей/покупателей собственного софта.

ЕМ>Структура записи примитивная — имя/фамилия, email, сведения о лицензиях (если есть), произвольные заметки (особенности использования программ, субъективные впечатления и т.п.).

LDAP сервер на выбор. И схемы подходящие уже есть, и допилить можно.

Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, varenikAA, Вы писали:

AA>>Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>Посоветуйте, пожалуйста, с помощью какой СУБД проще организовать ведение базы пользователей/покупателей собственного софта.

AA>>https://www.h2database.com/html/main.html

GIV>Это не продакшн вообще ни разу. Тесты только пускать можно на ней.

Писал на GRAILS = groovy + h2 + jetty многопользовательское веб-приложение для бухгалтеров для учет должников
с разным уровнем доступа. в те же времена использовали sql 2005. Так mssql частенько приходилось восстанавливать из копии. h2 работал как часы, не было случая чтобы база полетела.

Здравствуйте, varenikAA, Вы писали:

AA>>>https://www.h2database.com/html/main.html

GIV>>Это не продакшн вообще ни разу. Тесты только пускать можно на ней.

AA>Писал на GRAILS = groovy + h2 + jetty многопользовательское веб-приложение для бухгалтеров для учет должников
AA>с разным уровнем доступа. в те же времена использовали sql 2005. Так mssql частенько приходилось восстанавливать из копии. h2 работал как часы, не было случая чтобы база полетела.

Посмотрел чего они добились за последнее время. Мультитреадинг смотрю почти осилили (для MVStore).
И то прогресс, три года назад экпериментальная многопоточность вообще не работала.

Это у вас какой год то был? Не вчера же вы дохлый груви с игрушечной H2 вы выбрали?

Здравствуйте, GarryIV, Вы писали:

GIV>Это у вас какой год то был? Не вчера же вы дохлый груви с игрушечной H2 вы выбрали?

ну, где-то 1-2 версия grails кажется был, лет 10 назад.