Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Почему MySQL на клиентской программе - это плохо?  [new]
jdoe
Member

Откуда:
Сообщений: 3
Добрый день всем.

Задача:
Я пишу приложение для учёта товаров в небольшом магазине (физическом, не интернет-магазине). Товара там не так много и распродаётся он не особо быстро.
Платформа - PC под управлением Windows, язык - Java. Разумеется, такое приложение будет работать с базой данных. Внимание: приложение будет устанавливаться и использоваться только на одном компьютере, то есть там не будет модели "клиент-сервер"; только клиент, если можно так сказать.
Я выбираю между MySQL и MongoDB. Знаю, что в данном случае особой разницы, чем пользоваться, нет; знаю также и об отличиях этих СУБД. Вопрос не в этом. Мне сказали, что использовать как MongoDB так и MySQL в клиентской программе это неправильный подход, и что лучше в этом случае было бы пользоваться SQLite.

Вопрос:
Почему использование MySQL в данном случае было бы плохим решением? Действительно ли лучше воспользоваться SQLite?

Спасибо!
5 дек 16, 02:48    [19966558]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
jdoe,

Не истины ради, а флейма для.
MySQL вообще нигде не надо использовать.
А лучше вообще забыть о существовании данной БД. :-)

А так есть же FireBird.
Embedded версия вполне подходит для большинства задач.
5 дек 16, 06:58    [19966603]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
jdoe,

1C до Израиля не дошел? Так-то скорее всего подобная задача уже написана
5 дек 16, 07:49    [19966655]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
мимопроходилтреднечитал
Guest
jdoe,

Всё правильно говорят, ещё на h2 посмотри, ибо мускуль — оверкилл для твоей задачи. А необучаемого из девяностых с фаербёрдом не слушай.
5 дек 16, 08:19    [19966691]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
jdoe
Я пишу приложение для учёта товаров в небольшом магазине (физическом, не интернет-магазине). Товара там не так много и распродаётся он не особо быстро.
Внимание: приложение будет устанавливаться и использоваться только на одном компьютере, то есть там не будет модели "клиент-сервер"; только клиент, если можно так сказать.
MS Excel/MS Access.
5 дек 16, 10:11    [19966957]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Yo.!
Guest
jdoe
Вопрос:
Почему использование MySQL в данном случае было бы плохим решением? Действительно ли лучше воспользоваться SQLite?

Спасибо!

не слушай их. если комп полноценный, то смысла пытаться экономить и ставить не полноценного клиент-сервера нет никакого. у тебя объемы крошечные, поэтому на первое место выходит задача как не проебать базу если сдохнет винт, как восстановить на момент перед сбоем и прочие, а не как сэкономить пару мегабайт на машине с гигабайтами оперативы и терабайтными дисками
..
5 дек 16, 11:06    [19967216]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Yo.!,

Много ты видел обычных компьютеров с более чем одним винтом?

jdoe
Внимание: приложение будет устанавливаться и использоваться только на одном компьютере, то есть там не будет модели "клиент-сервер"; только клиент, если можно так сказать.


поэтому вот это

Yo.!
поэтому на первое место выходит задача как не просрать базу если сдохнет винт, как восстановить на момент перед сбоем и прочие


фигня на постном масле. Восстанавливаться перед сбоем будет просто не с чего, если сдохнет винт. Повезёт если клиент вообще резервную копию БД куда нибудь на флешку скидывать будет.
5 дек 16, 12:26    [19967591]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Yo.!
Guest
Симонов Денис
фигня на постном масле. Восстанавливаться перед сбоем будет просто не с чего, если сдохнет винт. Повезёт если клиент вообще резервную копию БД куда нибудь на флешку скидывать будет.

о том и речь, чуваку надо думать не о клиент-сервере, а о сохранности данных. о логах и втором диске.

p.s. даже очень небольшой магазин потянет второй диск под бэкап и лог, благо цена даже нового диска 8-15 евро (80GB)
5 дек 16, 13:02    [19967776]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54812

jdoe
Мне сказали, что использовать как MongoDB так и MySQL в клиентской программе это
неправильный подход, и что лучше в этом случае было бы пользоваться SQLite.

А эти странные люди чем-то своё заявление аргументировали? Я, вот, например, могу сказать,
что использовать Java в клиентской программе это неправильный подход и лучше пользоваться
Delphi или C++. Послушаешься?..

PS: SQLite из Java это должен быть забавный секс...

Posted via ActualForum NNTP Server 1.5

5 дек 16, 13:23    [19967865]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
Dimitry Sibiryakov
SQLite из Java это должен быть забавный секс...
Почему?
5 дек 16, 13:35    [19967917]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
antares0
Member

Откуда:
Сообщений: 247
jdoe,
MySQL поднимает сервер отдельный от приложения. Иногда это приводит к странным глюкам. Я работал с такой прогамой. Лучше FireBird он специально под это заточен.

> Действительно ли лучше воспользоваться SQLite?
Если понимаешь чем SQLite отличается от серверных вариантов. Если нет то смотри выше.
5 дек 16, 14:23    [19968243]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
schi
Member

Откуда: Москва
Сообщений: 2601
antares0
MySQL поднимает сервер отдельный от приложения. Иногда это приводит к странным глюкам.


Oracle тоже поднимает сервер, отдельный от приложения. К глюкам это не приводит.
5 дек 16, 14:33    [19968313]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6642
jdoe
...Внимание: приложение будет устанавливаться и использоваться только на одном компьютере, то есть там не будет модели "клиент-сервер"; только клиент, если можно так сказать....

А если дела пойдут хорошо, и откроется 2й, 3й,...5й магазины. Что тогда?
5 дек 16, 14:43    [19968369]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
Siemargl
А если дела пойдут хорошо, и откроется 2й, 3й,...5й магазины. Что тогда?
Тогда ТС точно сможет себе позволить нанять хороших специалистов, и обратится на sql.ru уже не с техническими вопросами, а с "Крупной сети магазинов требуется ...".
5 дек 16, 14:52    [19968429]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Vladimir Baskakov
Member

Откуда:
Сообщений: 2006
antares0
Лучше FireBird он специально под это заточен.


а расскажите, как FB embedded использовать с java - какие библиотечки по каким путям раскладывать, какой jdbc дайвер брать, так чтобы сразу стало хорошо. а то, есть подозрение что с таким гибридом маеты много.
=====================
jdoe
- удобство java как языка разработки для этой задачи представляется сомнительным; а mySql - почему бы и нет. База как база. в случае чего, интерфейс на php переделать, и вот уже клиент-сервер.

Вот монго бы я не взял, для такой задачи.
5 дек 16, 14:54    [19968440]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
antares0
Member

Откуда:
Сообщений: 247
Vladimir Baskakov,
Обыкновенный jaybird. В faq-е firebird-а все разжевано. С другой стороны на новых виндах я это не проверял:(
mySql - почему бы и нет. База как база.

Затык в том что для ее использования на десктопе нужны хотя бы минимальные знания по администрированию. У новичков сходу их обычно нет, что порождает всякое неординарное. С Firebird в этом смысле проще. Он пусковые работы сервера берет на себя.
5 дек 16, 17:06    [19969155]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6642
antares
Лучше FireBird он специально под это заточен. ...,
Обыкновенный jaybird. В faq-е firebird-а все разжевано. С другой стороны на новых виндах я это не проверял:(
mySql - почему бы и нет. База как база.

Затык в том что для ее использования на десктопе нужны хотя бы минимальные знания по администрированию. У новичков сходу их обычно нет, что порождает всякое неординарное. С Firebird в этом смысле проще. Он пусковые работы сервера берет на себя.

А ты использовал FB с Явой посложнее хелловорлда, или просто потрындеть?

Потому что FB заточен свой под низкоуровневый С API и Дельфи, а со всем остальным вечные проблемы, которые _не касаются_ разработчиков FB - обращайтесь к тому самоделкину, кто драйвер писал.
См.профильный топик.
6 дек 16, 00:09    [19970426]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Siemargl
Потому что FB заточен свой под низкоуровневый С API и Дельфи, а со всем остальным вечные проблемы, которые _не касаются_ разработчиков FB - обращайтесь к тому самоделкину, кто драйвер писал.


API тут не причём. Компоненты Дельфи просто используют этот API. И научились они использовать API ещё с незапамятных времён. Кардинально API не меняется в отличие от других вещей, например сетевого протокола. А поскольку .NET и Java не используют fbclient, то им приходится самим реагировать на все изменения и делать свою реализацию всего того, что уже реализовано в fbclient. Естественно поддержка самых последних фич будет отставать, так как этими драйверами занимается другая команда разработчиков (а не самоделкиных).
6 дек 16, 10:01    [19970905]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Vladimir Baskakov
Member

Откуда:
Сообщений: 2006
так если мускуль под виндой поставить, он сам вроде как сервис запускаться начнет. особых хлопот на одной машине нет. а на связке f-bird embedded с java хлопот и особенностей не меньше, как по мне.

судя по
http://www.firebirdfaq.org/faq350/
все равно jdbc драйвер будет дергать jabird.dll, а последний - за клиента. бабка за дедку, дедка за репку, что где отвалилось я не виноват. причем там какие то конфиги все равно незаметно лежат

если нужно в java встраивать sql - это h2. но там, кажись, своих особенностей никак не меньше, подзыбыл уже, не хранятся ли таблички в чистом csv? что-то я пробовал, и смутило меня, уж не помню что.

в общем, mySql не представляется одиозным решением. да и firebird в режиме сервера, возможно - тоже поставился, стал сервисом (если под виндой). но я бы формочки для мускуля или огнептицы делал бы в лазарусе, по мне понятнее, но дело вкуса.

вот, коллега развлекался с разрядностью драйвера для огнептица, правда давно:
http://javatalks.ru/topics/25586
может лучше нынче все, не знаю....
6 дек 16, 10:37    [19971098]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11476
В JDK, начиная с Java7 (6?) идёт Apache Derby.
JDBC определяет четыре типа драйверов:
1. JDBC-ODBC: не рекомендуется, выпилено;
2. Native: штатные клиентские библиотеки с JNI-обвязкой;
3. "Промежуточный": на клиенте - "ява-пюре", которое обращается к промежуточному серверу;
4. Pure Java: "ява-пюре" реализация клиентских библиотек.
Тип 3 мне как-то не попадался, с типом два (jaybird/oracle thick) - не возился, тип 4 (jaybird/oracle thin) - то, что доктор прописал для "отдельного" сервера БД.
Тип четыре (по определению) не зависит от разрядности, но, мягко говоря, малопригоден для встраивания "non-java db".

P.S. Судя по настройкам, которые впендюрили, например, разработчики OpenFire - программисты просто не умеют готовить h2.
Вероятно - не только её и не только во встраиваемом варианте.
6 дек 16, 16:57    [19973473]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
jdoe
Member

Откуда:
Сообщений: 3
Всем спасибо за ответы!
Мне ответили ещё вот что: MySQL кушает порядка 150МB памяти когда idle. Плюс SQLite встраиваемый и поэтому не надо устанавливать ничего отдельно, только само приложение, которое им пользуется.

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

Yo.!
У клиента имеется отдельный диск, на который данные автоматически копируются время от времени, так что восстановление не должно стать проблемой. Кстати, компьютер у него не самый сильный, управляется ХР (правда, к тому моменту как я допишу приложение, он уже должен перейти на 8 или 10).

antares0
Уже понял, благодарю :)

Siemargl
Такой возможности клиент не предвидит, посему и не требует её поддержки..

В итоге я стал работать с SQLite, посмотрел checklist на сайте проекта https://sqlite.org/whentouse.html, он подходит под мой случай. Использование с Java несложно: достаточно просто скачать драйвер и прикрепить его к проекту, больше ничего не требуется. Драйвер работает хорошо.
7 дек 16, 00:42    [19974590]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
ТиФорс
Member [заблокирован]

Откуда: 7655112
Сообщений: 229
jdoe,

Если используешь MS VS для разработки, то ответ - понятен, SQL Server. Его каких только модификаций нет, на все случае жизни.
7 дек 16, 00:50    [19974606]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54812

ТиФорс
Если используешь MS VS для разработки

А он что, уже научился и Java понимать?..

Posted via ActualForum NNTP Server 1.5

7 дек 16, 01:08    [19974627]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Yo.!
Guest
jdoe
Yo.!
У клиента имеется отдельный диск, на который данные автоматически копируются время от времени, так что восстановление не должно стать проблемой.

автоматически копировать бэкап можно и по нетворку, для этого второй хдд нафиг не нужен. второй хдд нужен для лога транзакций. он позволяет восстановить базу (не firebird конечно же) на момент прямо перед сбоем. без лога ты только на момент бэкапа можешь восстановится, т.е. часть данных будет потерна и клиенту надо будет угадывать чего пропало.
7 дек 16, 07:38    [19974750]     Ответить | Цитировать Сообщить модератору
 Re: Почему MySQL на клиентской программе - это плохо?  [new]
Garrick
Member

Откуда: Москва
Сообщений: 3166
jdoe
Добрый день всем.

Задача:
Я пишу приложение для учёта товаров в небольшом магазине (физическом, не интернет-магазине). Товара там не так много и распродаётся он не особо быстро.
Платформа - PC под управлением Windows, язык - Java. Разумеется, такое приложение будет работать с базой данных. Внимание: приложение будет устанавливаться и использоваться только на одном компьютере, то есть там не будет модели "клиент-сервер"; только клиент, если можно так сказать.
Я выбираю между MySQL и MongoDB. Знаю, что в данном случае особой разницы, чем пользоваться, нет; знаю также и об отличиях этих СУБД. Вопрос не в этом. Мне сказали, что использовать как MongoDB так и MySQL в клиентской программе это неправильный подход, и что лучше в этом случае было бы пользоваться SQLite.

Вопрос:
Почему использование MySQL в данном случае было бы плохим решением? Действительно ли лучше воспользоваться SQLite?

Спасибо!


Для Java на мой взгляд правильнее использовать что-то из:
- Apache Derby, она же JavaDB - уже есть в комплекте JDK, может быть использована как сервер базы данных или как embedded вариант. Во втором случае пользователь вообще не будет знать что у него есть какая-то база данных, которую нужно запускать отдельно от приложения. Для данной базы допускается написание встроенных процедур на Java. Имеется очень подробное и внятное руководство пользователя/разработчика/администратора.
- Альтернативные, мало чем отличающиеся варианты: HSQLDB и H2

А SQLite в связке с Java не самый лучший выбор. Если, конечно, не на Android'е. Там альтернативы фактически нет.
7 дек 16, 09:06    [19974844]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить