Многопользовательская локальная БД?

Question

[Андрей Григорьев]

Необходимо написать приложение в котором содержится таблица с текстовыми записями. Примерно 1500 записей в год. Одновременное подключение порядка 5-10 пользователей.
Хочется чтобы приложение использовало собственную локальную БД. Чтобы использовать расшаренную папку, т.е. без установки отдельного сервера БД.

Какую многопользовательскую локальную БД лучше использовать?

Comments

[Андрей Григорьев]

Хочется что-то вроде firebird embedded или sqlite. Для масштабирования в будущем.
Но у перечисленных мною БД проблемы с одновременным доступом к БД с разных ПК.
Есть вариант MS Access. Есть ли ему альтернативы?

[Everything_is_not_so_bad]

Речь о настольных приложениях? Или веб-сайте? Лучше уточнить тегами, отредактировав вопрос.

[Андрей Григорьев]

Роман Мирр: Настольное приложение.

Answer 1

[Roman K]

SQLite. Поддерживает несколько соединений (но писать в БД всё равно может только один. Но это ничего, 1500 инсертов в год клиенты переживут)

Answer 2

[Nivka]

1500 записей в ГОД?
Какая БД?
Текстовые файлы.

Comments

[DDDsa]

А как же аналитика? Разве есть аналоги SQL для текстовых файлов?

[Nivka]

Даниил: Зачем?
1500 записей отлично грузятся в оперативку и тупа ищутся перебором.

[DDDsa]

Nivka: Ну, это уж зависит от задач. Начальник может каждый день просить новый отчет, а если логика сложная, то запрос написать куда проще, чем возиться с массивами вручную : )

[Roman K]

Nivka: Как будешь консистентность организовывать в файлах своих? :) Обёртки тоже будешь свои писать для файлов своих? :)

[abcyu]

Roman Kitaev: Зачем? Если всего 1500 записей в год.

[Roman K]

abcyu: Ага, тоесть, по-твоему, если записей 1500 в год, то их вообще нет?) И если их всего 1500 в год, то конкурентной записи не бывает?)

[abcyu]

Roman Kitaev: 4-5 раз в день? Примерно раз в 2 часа в течение рабочего дня?
Бывает и конкурентная.

Решается просто - файловым флагом.

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

Но вполне можно обойтись флагом.

[Roman K]

abcyu: Я завидую тебе, если ты думаешь, что 1500 размазана равномерно по году.

[abcyu]

Roman Kitaev:
Да без разницы. Хоть 12 раз в год.

Глядите на архитектуру шире - вам ведь столько подсказок дали в последнее время, что это бывает довольно эффективно.
Тут вам и NoSQL и memcache и пр. Нет, ухватятся за свой LAMP, будто кроме MySQL в природе никого нет.

Кстати о файлах: захотелось мне провести эксперимент - и все получилось.
У меня хорошо посещаемый интернет-магазин прекрасно на файлах работал года 3 - принес кучу денег и разработчикам и владельцу. Порядка 300 заказов в день - никаких проблем с хранением данных о заказываемых товарах в файлах.

[Roman K]

abcyu: А кто говорит про NoSQL и тем более причём тут мемкэш? Я говорю о том, зачем пользоваться изначально костыльным решением, даже если готовый SQLite кажется оверхэдом? Ты сможешь за себя сказать: "я написал эту квази-базу на файлах и уверен в её консистентности больше, чем всё комьюнити sqlite (у которого, кстати, бзик на тестах) за свой sqlite"?

[abcyu]

Roman Kitaev:
Не про данный случай - NoSQL, memcache, хранение в файлах - смотрите на жизнь шире.
Не зашоривайтесь на единственном решении - только SQL и только MySQL и SQLite.

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

[abcyu]

Roman Kitaev:
Конечно уверен:
1. Архитектура создана так, что консистентность не может быть нарушена пока жива файловая система.
2. Все проверено годами.

P.S.:
Там вообще нет НИЧЕГО сложного.
Просто люди, которые в жизни никаких БД кроме MySQL не видели не могут понять - насколько все ПРОСТО.

[Roman K]

abcyu: Ну, допустим, я скажу, что поюзываю монгу и мемкэш. Что ты к ним привязался?) Головой надо думать, тут ты прав: нечего сувать NoSQL во все щели и пытаться уткнуть бедных SQLщиков в своей недальновидности. Мемкэш. Господи, для 1500 записей в базе юзать мемкэш (или зачем ты его сюда второй раз приплёл?)? Любой сложности селект пройдётся по этой базе сотню раз, ты и глазом не моргнёшь.

[abcyu]

Roman Kitaev:
Все эти технологии приплетены сюда с единственной целью - чтобы люди начали мозгой шевелить.

Для такой задачи сервер БД избыточен?
Ну так давайте выкинем его. Зачем за него держаться то.

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

[Roman K]

abcyu: Сразу видно ответ человека, который не умеет экономить своё время.

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

То обнаружу зря портаченное время.

1500 за день не является проблемой.

У меня сейчас на постгресе стоит парсер и 1000 инсетров за секунду туда влетает и не является проблемой.

[abcyu]

Roman Kitaev: для файлов это тоже не является проблемой.
незачем пихать SQL туда где он не нужен.

[Roman K]

abcyu: Ну-ка, дай пример мне. Приложи заодно результаты htop и iotop во время транзакций. Самые стандартные CRUD хотя бы.

[abcyu]

Roman Kitaev: Для этого нужно реализовать 2 идентичных системы и произвести замер. Зачем мне это? Я ленюсь. Вам нужно - Вы и проверяйте. Для себя я все решил еще несколько лет назад. Я знаю что это так и иногда использую файлы, если это адекватно задаче.

[Roman K]

abcyu: "Мне настолько всё равно, что я не могу об этом молчать"

[abcyu]

Roman Kitaev: Ну дык и мне все равно - повысите вы свой квалификационный уровень или нет. Я вам высказал идею - хочешь верь хочешь не верь. Я для себя уже все давно проверил ))))

[Roman K]

abcyu: Было бы всё равно - ты бы не поднимал тему полумесячной давности )
Причём,

Вам нужно - Вы и проверяйте.

Мне ничего не нужно. Спор, помнится, завёл ты со мной со слов:

Roman Kitaev: Зачем? Если всего 1500 записей в год.

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

Я думал, логика за твои "20 лет" работы должна быть на высшем уровне))

[abcyu]

Roman Kitaev: Было бы всё равно - ты бы не поднимал тему полумесячной давности )
Да не преувеличивайте. Вся страна отдыхала 10 дней. И на отдыхе мне было не до интернета )))

[abcyu]

Roman Kitaev: решение в каждом случае принимается индивидуально.
предположительно, в этом случае при 1500 записях в ГОД можно прекрасно все прочитать полностью в оперативку.

[skrimafonolog]

Roman Kitaev,

А кто говорит про NoSQL и тем более причём тут мемкэш? Я говорю о том, зачем пользоваться изначально костыльным решением, даже если готовый SQLite кажется оверхэдом?

Ну сделайте сразу кластер из СУБД.
;)

Вам предложили совершенно здравое решение, не костыльное отнюдь.

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

[skrimafonolog]

Roman Kitaev,

Приложи заодно результаты htop и iotop во время транзакций. Самые стандартные CRUD хотя бы.

Ты серьезно?
Файловые БД всегда были быстрее полноценных СУБД из за более примитивной поддержки транзакций.

А тут вам вообще предлагают все в оперативке.

Вы точно - программист?
По уровню понимания - нет.

Answer 3

[Everything_is_not_so_bad]

Сначала тоже подумал о SQLite, но прочтя про

Одновременное подключение порядка 5-10 пользователей.

всё таки подходит MySQL/MariaDB, поскольку для SQLite только один пользователь имеет право на запись в БД в одно время.
Configuring MySQL to use minimal memory

А решения с файлами скорее всего будут велосипедами, так как нужно учитывать блокировки.
На расшаренной папке СУБД нельзя ставить - данные могут быть повреждены/потеряны по причине тех же блокировок и потенциальных проблем с сетями.
Итого, нужно иметь СУБД на выделенном ПК/сервере, если речь о настольных приложениях.
Если с ресурсами совсем напряжёнка, то можно установить на один из ПК. Главное, чтобы этот ПК никогда не выключался и стоял с ИБП.

Comments

[Roman K]

Что мешает поставить ожидание на право на запись?

[Roman K]

Хотя, я бы всё равно пользовался серверными решениями, а не городил велосипед из SQLit'ов. Не для этого он нужен.

Answer 4

[DastiX]

Firebird однозначно.

Comments

[abcyu]

Он еще жив?

[DastiX]

Он живее всех живых. RC1 3.0 уже в продакшене, так что можно смело брать. Всяко лучше чем убогий SQLite.