ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Почему MySQL на клиентской программе - это плохо?
21 сообщений из 46, страница 2 из 2
  2  все
Почему MySQL на клиентской программе - это плохо?
    #39361660
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
авторПлатформа - PC под управлением Windows, язык - Java .

А эта адская смесь зачем?!

Visual Studio Community +SQL Server Express успешно решат поставленную задачу по разработке десктопного клиента, раз уж так хочется заняться этим самостоятельно.
...
Рейтинг: 0 / 0
07.12.2016, 11:16
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39362021
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
pkarklinА эта адская смесь зачем?!Что адского в работе Java на одной из поддерживаемых платформ?
...
Рейтинг: 0 / 0
07.12.2016, 17:27
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39362022
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Basil A. SidorovЧто адского в работе Java на одной из поддерживаемых платформ?

Отсутствие использования системного GUI, например, из-за чего интерфейсы, рисуемые
графическими примитивами, выглядят чужеродно и работают медленно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
07.12.2016, 17:30
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39362028
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
"Не стандартные элементы управления" - соглашусь, "Медленно" - нет.
...
Рейтинг: 0 / 0
07.12.2016, 17:38
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39362061
Vladimir Baskakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir Baskakov
Участник
Basil A. SidorovpkarklinА эта адская смесь зачем?!Что адского в работе Java на одной из поддерживаемых платформ?

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

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

из любопытства попробовал, но так и не добил.... надо будет - на лазарусе накидаю, привычно. а в остальном - язык как язык, в принципе. так что для десктопа - не проникся.
...
Рейтинг: 0 / 0
07.12.2016, 18:15
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39362203
jdoe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jdoe
Гость
Yo.!jdoe Yo.!
У клиента имеется отдельный диск, на который данные автоматически копируются время от времени, так что восстановление не должно стать проблемой.
автоматически копировать бэкап можно и по нетворку, для этого второй хдд нафиг не нужен. второй хдд нужен для лога транзакций. он позволяет восстановить базу (не firebird конечно же) на момент прямо перед сбоем. без лога ты только на момент бэкапа можешь восстановится, т.е. часть данных будет потерна и клиенту надо будет угадывать чего пропало.

Вопрос о том, нужен ли второй хдд, не стоит, поскольку он у клиента уже есть (и давно), так что с этим понятно. Что же касается логов, то вот тут интересно. Некоторые возможности ведения логов, видимо, есть и в sqlite3 http://stackoverflow.com/questions/10910157/enable-query-logging-in-sqlite-3 . В крайнем случае почему бы самому не дописать простую возможность сохранения всех выполненных queries в какой-нибудь отдельный файл? Это и будет у нас журналом запросов, и оттуда можно будет восстановить базу.
...
Рейтинг: 0 / 0
08.12.2016, 01:30
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39362396
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
jdoeВопрос о том, нужен ли второй хдд, не стоит, поскольку он у клиента уже есть (и давно), так что с этим понятно. Что же касается логов, то вот тут интересно. Некоторые возможности ведения логов, видимо, есть и в sqlite3 http://stackoverflow.com/questions/10910157/enable-query-logging-in-sqlite-3 . В крайнем случае почему бы самому не дописать простую возможность сохранения всех выполненных queries в какой-нибудь отдельный файл? Это и будет у нас журналом запросов, и оттуда можно будет восстановить базу.
выкрутиться можно из любой ситуации, просто не понятен смысл. конечно можно и свои велосипеды лепить, но однажды, в 6 утра понедельника, после двухдневного запоя, тебе позвонит тупой пользователь с загубленой базой, но как на зло именно в тот понедельник твой велосипед вылетает с null point exception и хер знает почему.
хотя ... может через это должен пройти каждый :D
...
Рейтинг: 0 / 0
08.12.2016, 11:36
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39362495
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
pkarklinVisual Studio Community +SQL Server ExpressЯ даже больше скажу - SQL Server LocalDB. Дистриб весит всего ничего, даже по сравнению с Express, руками через гуй устанавливать не надо (MSI вызывается с соотв. ключами из инсталлятора программы), настраивать не надо, запускается под правами вызывающего пользователя.

При этом ограничения, как у Express - 10 гиг на БД, например (не думаю, что упретесь в это). Ну и разумеется бэкапы и все остальное.

У меня есть один такой проект, WinForms + LocalDB. Уже больше года продается, проблем нет.
...
Рейтинг: 0 / 0
08.12.2016, 12:59
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39362517
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Dimitry SibiryakovBasil A. SidorovЧто адского в работе Java на одной из поддерживаемых платформ?

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

Ну, с точки зрения перфекциониста, да. Но в целом, не выглядит медленнее, например WPF.

Плюс Явы - можно будет перетащить на Линух станцию с довольно таки минимальными проблемами. Минусы, конечно тоже есть. Как и везде.

PITR - оверкилл для маленькой задачи (да и использовать его не так уж очевидно). Проще ручками бэкапить всю базочку каждый час.
...
Рейтинг: 0 / 0
08.12.2016, 13:27
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39362536
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
SiemarglНо в целом, не выглядит медленнее, например WPF.
Это ты нашёл очень правильный объект для сравнения. Qt ещё не забудь.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.12.2016, 13:53
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39363475
Garrick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garrick
Участник
Dimitry SibiryakovBasil A. SidorovЧто адского в работе Java на одной из поддерживаемых платформ?

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


Про SWT ничего не слышали?
...
Рейтинг: 0 / 0
09.12.2016, 14:19
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39363919
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Garrick,

ТСу расскажи, он мамонтов точно не видел
...
Рейтинг: 0 / 0
09.12.2016, 23:48
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39363927
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Симонов ДенисSiemarglПотому что FB заточен свой под низкоуровневый С API и Дельфи, а со всем остальным вечные проблемы, которые _не касаются_ разработчиков FB - обращайтесь к тому самоделкину, кто драйвер писал.

API тут не причём. Компоненты Дельфи просто используют этот API. И научились они использовать API ещё с незапамятных времён. Кардинально API не меняется в отличие от других вещей, например сетевого протокола. А поскольку .NET и Java не используют fbclient, то им приходится самим реагировать на все изменения и делать свою реализацию всего того, что уже реализовано в fbclient. Естественно поддержка самых последних фич будет отставать, так как этими драйверами занимается другая команда разработчиков (а не самоделкиных).
Ну кроме того, что ты одного разработчика считаешь за "команду", ничего противоречащего ты не сказал.

Общий же уровень подержки сторонних разработчиков (кроме Дельфи и С-API) для ФБ выглядит _всегда_ так (см. тоже "команда"):
http://www.sql.ru/forum/1221567/ado-net-firebird-gluki#19987040
МимопроходящийHello, Rjkz!
You wrote on 18 июля 2016 г. 10:58:21:

Rjkz> Установил провайдер версии 4.1.0.0 - таже хрень.текущий 5.0.5.0
а вообще, как уже было сказано выше, все вопросы по провайдеру нужно задавать его автору - Jiří Činčura.тут ADO.NET никто не использует, и тем более не разрабатывает вышеобозначенный провайдер.
...
Рейтинг: 0 / 0
10.12.2016, 00:23
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39364075
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Yo.!о том и речь, чуваку надо думать не о клиент-сервере, а о сохранности данных. о логах и втором диске.


Ну могут же и оба диска выйти из строя. Потоп, Пожар. Ему лучше организовать резервную БД на втором компе.
...
Рейтинг: 0 / 0
10.12.2016, 14:36
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39371735
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
jdoe
Вопрос:
Почему использование MySQL в данном случае было бы плохим решением? Действительно ли лучше воспользоваться SQLite?

Спасибо!

ответ один: потому что не надо слушать всяких козлов. Люди могут нести любую чушь, 95 % людей вообще идиоты. значит, ты должен понимать прежде всего, кого ты читаешь, что это за тип, и зачем он тебе это говорит.

это кстати не значит, что ты не можешь использовать SQLite, а вовсе и наоборот, можешь.

а вот с монгой я бы не советовал связываться, негибко.

с SQLite подумай, что будет если твой магазин завтра расширится, и они наймут еще 4 человека продавцов.
...
Рейтинг: 0 / 0
21.12.2016, 11:50
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39371743
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
мимопроходилтреднечиталjdoe,

Всё правильно говорят, ещё на h2 посмотри, ибо мускуль — оверкилл для твоей задачи. А необучаемого из девяностых с фаербёрдом не слушай.

вот типичный пост - пример того, о чем я говорил, те самые 95 %.

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

хочешь его слушать?

объективности ради, да, my SQL - не самая лучшая в мире СУБД, но она стабильная, зрелая, и для несложного проекта вполне сгодится, к тому же по ней много ресурсов, много спецов, так что можно получить совет (90 % будут опять же советы от лохов, но это нормально).
...
Рейтинг: 0 / 0
21.12.2016, 11:55
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39372438
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
vadiminfoYo.!о том и речь, чуваку надо думать не о клиент-сервере, а о сохранности данных. о логах и втором диске.


Ну могут же и оба диска выйти из строя. Потоп, Пожар. Ему лучше организовать резервную БД на втором компе.
ну это уже задешевого не организуешь, а два диска и перенос "арклогов" вполне годиться среднему магазину. если диски погибли, пропадет час-два, это в магазинах с чеков/бумаг обычно еще реально забить заново.
...
Рейтинг: 0 / 0
21.12.2016, 23:06
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39373499
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
MasterZivа вот с монгой я бы не советовал связываться, негибко.Хм, что негибко?
...
Рейтинг: 0 / 0
23.12.2016, 09:51
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39373500
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
5 лет MongoDB на продакшн, отсутсвия гибкости не замечено.
...
Рейтинг: 0 / 0
23.12.2016, 09:54
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39377209
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
skyANAMasterZivа вот с монгой я бы не советовал связываться, негибко.Хм, что негибко?

Структура базы данных.
...
Рейтинг: 0 / 0
28.12.2016, 19:51
| Ответить | Цитировать | Написать  
Почему MySQL на клиентской программе - это плохо?
    #39377286
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
MasterZivskyANAпропущено...
Хм, что негибко?

Структура базы данных.
Бррр... Schemaless , куда уж гибче?
...
Рейтинг: 0 / 0
28.12.2016, 22:56
| Ответить | Цитировать | Написать  
21 сообщений из 46, страница 2 из 2
  2  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Почему MySQL на клиентской программе - это плохо?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&msg=39362021&tid=1552248]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 135ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 64ms
get tp. blocked users:
 2ms
others: 14ms
total:  260ms
созд. / загр.: 260ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]