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

Откуда: Петрозаводск
Сообщений: 52
Доброго времени суток!

Есть задача написать клиент-серверное CRUD-приложение (толстый клиент). Несколько удалённых офисов, ширина канала до сервера баз данных - (sic!) 128 кбит/с. Текущая поделка на Access 2007 безбожно тормозит. Посоветуйте что лучше использовать для реализации?

Изначально планируется клиент на Delphi. Вопрос в выборе СУБД (MySQL, PostgreSQL, etc..) и в выборе технологии коннекта (ADO, FireDAC, etc..)
11 май 16, 11:51    [19157267]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Dimitry Sibiryakov
Member

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

asphix
Посоветуйте что лучше использовать для реализации?

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

PS: MySQL бери, ему хуже уже не будет.

Posted via ActualForum NNTP Server 1.5

11 май 16, 12:15    [19157487]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sergey Orlov
Member

Откуда: СПб
Сообщений: 4508
А базы с репликацией вы не рассматривали? впрочем, тут все зависит от специфики работы...
11 май 16, 12:26    [19157579]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

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

Тут, имхо, дело не столько в СУБД, сколько в специфике написания запросов.
1) Никаких SELECT * FROM mytable, выбирать только нужные поля и только нужные записи.
2) Минимизировать количество запросов. Тут вариантов множество. Мне, например, приходилось сериализовать записи из detail-таблицы и соединять с мастер-таблицей, чтобы все данные выбрать за один запрос, а не терзать СУБД потом сотней маленьких запросов к detail-таблице. Не переоткрывать датасеты по каждом чиху и т.д. Возможно, что-то кэшировать локально (в датасетах или даже в файлах).
3) Пункт, противоположный пункту 1. Выбирать (например, при старте приложения) в датасет небольшие неизменяемые таблицы и потом фильтровать их локально, без повторных обращений.
11 май 16, 12:38    [19157670]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
asphix
Member

Откуда: Петрозаводск
Сообщений: 52
miksoft, Спасибо за советы.

Осталось понять, какие технологии (ADO, FireDAC, etc..) умеют кеширование в датасетах.

Sergey Orlov, репликацию рассматриваю, проблема лишь в том, что в клиентских сегментах нет возможности доп. базы развернуть, кроме, разве что, sqlite..
11 май 16, 13:24    [19158060]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
asphix
какие технологии (ADO, FireDAC, etc..) умеют кеширование в датасетах.
Любые, где вообще есть датасеты или их аналоги. Под кэшированием понималось использование датасетов для этих целей, а не какие-то специфические механизмы в них.
11 май 16, 13:55    [19158345]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sergey Orlov
Member

Откуда: СПб
Сообщений: 4508
asphix
miksoft, Спасибо за советы.
Осталось понять, какие технологии (ADO, FireDAC, etc..) умеют кеширование в датасетах.
Sergey Orlov, репликацию рассматриваю, проблема лишь в том, что в клиентских сегментах нет возможности доп. базы развернуть, кроме, разве что, sqlite..

А перейдите на веб, тогда вам пофиг будет канал, вам ведь не анимацию по нему гонять...
11 май 16, 14:01    [19158416]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Sergey Orlov
А перейдите на веб, тогда вам пофиг будет канал, вам ведь не анимацию по нему гонять...
Там тоже есть своя специфика.
Некоторые любят сотни КБ Javascript-a гонят :)
11 май 16, 14:07    [19158465]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sergey Orlov
Member

Откуда: СПб
Сообщений: 4508
miksoft
Sergey Orlov
А перейдите на веб, тогда вам пофиг будет канал, вам ведь не анимацию по нему гонять...
Там тоже есть своя специфика.
Некоторые любят сотни КБ Javascript-a гонят :)

Программистов под php море... Хотя везде своя специфика...
Кстати если уже есть программа под Аксесс, то ее тоже можно юзать с SQL-сервером, доработав конечно...
11 май 16, 15:49    [19159139]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9882
asphix
ширина канала до сервера баз данных - (sic!) 128 кбит/с. Текущая поделка на Access 2007 безбожно тормозит. Посоветуйте что лучше использовать для реализации?

Кроме "ширины" канала, есть еще latency (задержка).

Приложение на Oracle Forms совершенно комфортно работало и на 32 kбит/с если маленькие задержки, но когда у одного пользователя был радио-канал 2 Mb/s с безумным разбросом задержек.... все, тушите свет.

Как вариант можно попытаться рядом с сервером базы данных поднять терминальный сервер и запускать приложения на нем
11 май 16, 16:46    [19159549]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Кстати, без хранимых процедур не обойтись.
Из бесплатных - mysql отпадает сразу именно по этой причине.
11 май 16, 17:27    [19159743]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
ОКТОГЕН
Кстати, без хранимых процедур не обойтись.
Это почему же?
ОКТОГЕН
Из бесплатных - mysql отпадает сразу именно по этой причине.
Почему?
В MySQL есть хранимые процедуры.
11 май 16, 17:30    [19159759]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
miksoft
ОКТОГЕН
Кстати, без хранимых процедур не обойтись.
Это почему же?
ОКТОГЕН
Из бесплатных - mysql отпадает сразу именно по этой причине.
Почему?
В MySQL есть хранимые процедуры.

В хранимке очень удобно обрабатывать данные на сервере, не гоняя гигасы по сети.
В mysql по сравнению с другими СУБД их нет. Любой конкурент уделает мыскль на раз.
Та же птичка, к примеру.
11 май 16, 17:33    [19159772]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
ОКТОГЕН
В хранимке очень удобно обрабатывать данные на сервере, не гоняя гигасы по сети.
Это можно делать и без хранимых процедур. Простой SQL запрос тоже может "обрабатывать данные на сервере, не гоняя гигасы по сети".
ОКТОГЕН
В mysql по сравнению с другими СУБД их нет. Любой конкурент уделает мыскль на раз.
Обосновать можете?
11 май 16, 17:37    [19159799]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
leguo
Member

Откуда: откуда не ждали
Сообщений: 43
Господа.
Я может чего не понял, конечно. А терминалы здесь не помогут?
11 май 16, 17:39    [19159811]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Dimitry Sibiryakov
Member

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

ОКТОГЕН
В хранимке очень удобно обрабатывать данные на сервере, не гоняя гигасы по
сети.

То есть сначала кто-то, не подумав, загоняет необработанные данные в БД, а потом их там
обрабатывает, так?..

Posted via ActualForum NNTP Server 1.5

11 май 16, 17:40    [19159815]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
leguo
Я может чего не понял, конечно. А терминалы здесь не помогут?
Зависит от того, сколько будет одновременных сессий. Если одна-две, то помогут. Три-четыре - будет сильно некомфортно работать. Если более, то, имхо, вряд ли реально.
Кроме того, непонятно, какие требования предъявляются к печати.
11 май 16, 17:47    [19159883]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
miksoft
Это можно делать и без хранимых процедур. Простой SQL запрос тоже может "обрабатывать данные на сервере, не гоняя гигасы по сети".
ОКТОГЕН
В mysql по сравнению с другими СУБД их нет. Любой конкурент уделает мыскль на раз.
Обосновать можете?


miksoft
Это можно делать и без хранимых процедур. Простой SQL запрос тоже может "обрабатывать данные на сервере, не гоняя гигасы по сети".

Всё можно. Вопрос только в цене. То что вы на postgresql напишете за 10 минут,
вы часами отлаживать будете.
miksoft
Обосновать можете?

Что тут обосновывать? То что у mysql
нет хранимок? Вы попробуйте хранимки того или иного сервера - поймёте.
Ничего там прикольного нет, только ежли себя наказать не хотите.
Там даже транзакций нормальных нет. Про репликацию не говрю.
Если вам понадобятся нестандартные вещи - намаетесь, т.к. функционал по движкам размазан.
11 май 16, 17:50    [19159911]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Dimitry Sibiryakov
То есть сначала кто-то, не подумав, загоняет необработанные данные в БД, а потом их там
обрабатывает, так?..

Даже отчёты разные бывают.
Например, сжатый график из данных вытащить.
В этом классе задач не всегда один селект всё решит.
11 май 16, 17:54    [19159941]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
ОКТОГЕН
Всё можно. Вопрос только в цене. То что вы на postgresql напишете за 10 минут,
вы часами отлаживать будете.
А причем тут отладка (хотя и про нее неверно)?
Изначальный Ваш тезис был "не обойтись".
ОКТОГЕН
Что тут обосновывать? То что у mysql
нет хранимок? Вы попробуйте хранимки того или иного сервера - поймёте.
Пробовал не однократно. Для меня основная рабочая СУБД Оракл. Конечно, там возможности хранимок побогаче. Но не настолько, чтобы говорить, что в MySQL их нет.

В MySQL нет анонимных процедур, но это почти полностью компенсируется тем, что там есть пользовательские переменные сессионного уровня.
ОКТОГЕН
Там даже транзакций нормальных нет.
Есть.
ОКТОГЕН
Про репликацию не говрю.
Репликации со своими особенностями, но тоже есть.
ОКТОГЕН
Если вам понадобятся нестандартные вещи - намаетесь
Это в любой СУБД так - как только понадобятся нестандартные для это СУБД вещи - намаетесь. Т.е. это тоже не аргумент.
ОКТОГЕН
функционал по движкам размазан.
Сейчас это не имеет сильного практического значения, т.к. по факту используется только один движок - InnoDB (или его потомки в форках).
11 май 16, 17:59    [19159971]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
ОКТОГЕН
Даже отчёты разные бывают.
Например, сжатый график из данных вытащить.
В этом классе задач не всегда один селект всё решит.
В ряде случаев - да, хранимые процедуры сильно помогают. Но из этого никак не следует, что без них не обойтись.
11 май 16, 18:01    [19159986]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Симонов Денис
Member

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

лично мне в процедурном языке mysql неудобно многое

1. Возврат набора данных через временные таблицы это извращение
2. Обработка исключений крайне неудобная
3. Курсоры только явные, всяческие FOR SELECT сделать нельзя. Выход из курсоров тоже ужасен.
4. Триггеры ущербные. Несколько триггеров на одно событие не повесишь. Нету универсальных триггеров на несколько событий. В BEFORE INSERT триггерах значение автоинкрементных полей по какой-то причине ещё не известно.

Кроме того в самом SQL нету CTE, что сильно осложняет написание сложных запросов. По сравнению с CTE Devired tables сильно загромождает код. Нету рекурсивных запросов.

С остальным мириться можно, даже не совсем стандартным SQL.
11 май 16, 18:09    [19160046]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
miksoft
В ряде случаев - да, хранимые процедуры сильно помогают. Но из этого никак не следует, что без них не обойтись.

А зачем без них обходиться, если можно не обходиться?
Тем более что и по лицензиям mysql как минимум - конкуренты ей не уступают.
Автор темы вообще может всю логику обработки на SQL сервер вытащить,
а в качестве клиента тот же либр офис задолбить. Да и майкрософт можно оставить.
Чисто как оболочку для вызова хранимок.
Поставить одбц и погнали. Почему нет?
11 май 16, 18:24    [19160131]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Симонов Денис
1. Возврат набора данных через временные таблицы это извращение
Если возврат на клиента, то процедура может сама возвращать набор записей. И даже несколько наборов.

В целом - да, таковые недостатки есть.
Но имеют ли они существенное значение в задаче топикстартера - не уверен. Тут уже недостаточно информации от него.
11 май 16, 18:25    [19160138]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
asphix,
ставь на отдельную машину SQL - птичку,постгрес,
на какой-нить клиент ставь либы, пробуй к ним из акцесса постучаться.
Получится - вытаскивай обработку и хранение на SQL
11 май 16, 18:36    [19160197]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить