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

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

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

Изначально планируется клиент на Delphi. Вопрос в выборе СУБД (MySQL, PostgreSQL, etc..) и в выборе технологии коннекта (ADO, FireDAC, etc..)


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

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

В хранимке очень удобно обрабатывать данные на сервере, не гоняя гигасы по сети.
В mysql по сравнению с другими СУБД их нет. Любой конкурент уделает мыскль на раз.
Та же птичка, к примеру.


В MYSQL есть процедуры. Работают. Вполне сносный язык.
Есть проблемы, но на новой разработке можно использовать последнюю версию MySQL, где всё более-менее починино.
11 май 16, 20:23    [19160544]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
лично мне в процедурном языке mysql неудобно многое
1. Возврат набора данных через временные таблицы это извращение


Там нету такого. SELECT просто идёт клиенту, всё ОК.



2. Обработка исключений крайне неудобная

В последней версии всё сильно лучше.


3. Курсоры только явные, всяческие FOR SELECT сделать нельзя. Выход из курсоров тоже ужасен.
Ну, это -- да.


4. Триггеры ущербные. Несколько триггеров на одно событие не повесишь. Нету универсальных триггеров на несколько событий. В BEFORE INSERT триггерах значение автоинкрементных полей по какой-то причине ещё не известно.

А триггеры тут при чём? Ты о процедурах вообще, или о чём говоришь ? Триггеры к ним никак не относятся.


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

Это всё брызги, не самое важное.

Ну да, mySQL не лучшая субд, но всё же не такая уж и плохая.
11 май 16, 20:26    [19160557]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
AndrF
Member

Откуда:
Сообщений: 2201
В определенных случаях логичней заюзать терминалы - трафик при этом я бы не сказал что большой.
11 май 16, 23:22    [19161153]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
MasterZiv
1. Возврат набора данных через временные таблицы это извращение

Там нету такого. SELECT просто идёт клиенту, всё ОК.


Это конечно. Если я могу получить данные простым SELECT, то зачем мне процедура? Я поясню что я имел ввиду.
Допустим мне надо получить последовательность чисел от 1 до 10. На FB это выглядело бы следующим образом

CREATE PROCEDURE GEN_RANGE(START INT, FINISH INT) RETURNS (VAL INT)
AS
BEGIN
  VAL = START;
  WHILE(VAL <= FISNISH) DO
  BEGIN
     SUSPEND;
     VAL = VAL + 1;
  END
END

SELECT VAL FROM GEN_RANGE(1, 10)


никаких временных таблиц не нужно. В MySql ту последовательность от 1 до 10 мне бы пришлось сначала положить в таблицу а потом делать из неё SELECT внутри процедуры. Или я что-то не знаю?

Теперь дальше на сколько я знаю единственный способ вызвать ХП в MySQL это использовать CALL
CALL GEN_RANGE(1, 10)

Ну ладно в приложении с этим нет проблем. А вот как использовать набор данных возвращаемой процедурой внутри другой процедуры?

MasterZiv
А триггеры тут при чём? Ты о процедурах вообще, или о чём говоришь ? Триггеры к ним никак не относятся.


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

MasterZiv
Ну да, mySQL не лучшая субд, но всё же не такая уж и плохая.


Кто спорит. Работать можно и работаем. Но раз уж речь зашла о процедурах, то по сравнению со многими другими СУБД тут всё плохо.
12 май 16, 09:37    [19161827]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38921
Симонов Денис
В MySql ту последовательность от 1 до 10 мне бы пришлось сначала положить в таблицу а потом делать из неё SELECT внутри процедуры.
Для этого можно использовать любую имеющуюся таблицу. Да и таблица dual никуда не делась, хотя через нее неудобно.
Симонов Денис
А вот как использовать набор данных возвращаемой процедурой внутри другой процедуры?
Тут, увы, никак. Прямой возврат возможен только на клиента.
12 май 16, 10:28    [19162068]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
Симонов Денис
[Допустим мне надо получить последовательность чисел от 1 до 10. На FB это выглядело бы следующим образом

CREATE PROCEDURE GEN_RANGE(START INT, FINISH INT) RETURNS (VAL INT)
AS
BEGIN
  VAL = START;
  WHILE(VAL <= FISNISH) DO
  BEGIN
     SUSPEND;
     VAL = VAL + 1;
  END
END

SELECT VAL FROM GEN_RANGE(1, 10)


Мощно.
Сравните с постгресом.
select generate_series(1,10)
12 май 16, 11:18    [19162466]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Симонов Денис
Member

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

то что PG для этого придумал встроенную функцию это понятно. Вопрос был не конкретно в генераторе чисел от 1 до 10. Это лишь пример когда процедура должна генерировать данные, которые не получаются из запроса. Алгоритм то может быть сложнее и совсем другой
12 май 16, 11:41    [19162676]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
dvim
Member

Откуда: Санкт Петербург
Сообщений: 721
asphix,
-какие требования по работе приложения при пропадании канала.
на минуту/час /день?
-общий объем данных

От этого очень зависит логика.
12 май 16, 11:44    [19162692]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 53035
Нужно создавать локальные (региональные) БД и реплицировать по возможности.

Вообще странное это ограничение... на телефонных модемах там сидите штоли... ?
12 май 16, 12:14    [19162914]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5959
Кстати, оракл сжимает трафик sql*net, остальные рсубд тоже? Какие сжимают, какие - нет?
12 май 16, 13:19    [19163413]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5959
Беглый поиск дал: mssql server умеет сжимать только между своими инстансами, к клиенту не умеет; postgresql умеет только через openssl с какой-то версии, т.е. нужен именно ssl коннект. Что с остальными?
12 май 16, 13:27    [19163481]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
xtender
Кстати, оракл сжимает трафик sql*net, остальные рсубд тоже? Какие сжимают, какие - нет?


Firebird 3.0 по умолчанию не сжимает, но это можно включить.
По умолчанию не сжимает потому что в ЛВС это не имеет смысла, затраты на сжатие перекроют выигрыш от него.
12 май 16, 13:29    [19163501]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
asphix
Member

Откуда: Петрозаводск
Сообщений: 52
dvim, при пропадании канала всех собак вешают на сетевиков головного офиса и простой не критичен совсем. На это можно не ориентироваться.
12 май 16, 13:36    [19163530]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Dimitry Sibiryakov
Member

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

xtender
Что с остальными?

Firebird 3 сжимает zlib. Но против высокой латентности канала это бесполезно.

Posted via ActualForum NNTP Server 1.5

12 май 16, 13:56    [19163668]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5959
Симонов Денис,

глянул мельком - правильно я понимаю, что еще не зарелизили? это только в 3.0 RC2 пока?
12 май 16, 14:00    [19163693]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Симонов Денис
Member

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

куда то ты не туда смотришь. Релиз вышел 19 апреля.
http://www.firebirdsql.org/en/news/firebird-3-0-is-released/
12 май 16, 14:01    [19163707]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5959
Dimitry Sibiryakov,

http://web.firebirdsql.org/download/prerelease/rlsnotes/Firebird-3.0.0_RC2-ReleaseNotes.pdf
только в RC2?
12 май 16, 14:01    [19163708]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Симонов Денис
Member

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

http://www.firebirdsql.org/en/firebird-3-0-0/
12 май 16, 14:02    [19163714]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5959
Симонов Денис,

3.0 - да, но фичи этой там не обнаружил. Вижу только в RC2:
1. http://tracker.firebirdsql.org/browse/CORE-733
2. http://web.firebirdsql.org/download/prerelease/rlsnotes/Firebird-3.0.0_RC2-ReleaseNotes.pdf
12 май 16, 14:02    [19163715]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
чччД
Guest
xtender
Симонов Денис,

3.0 - да, но фичи этой там не обнаружил. Вижу только в RC2:
1. http://tracker.firebirdsql.org/browse/CORE-733
2. http://web.firebirdsql.org/download/prerelease/rlsnotes/Firebird-3.0.0_RC2-ReleaseNotes.pdf


http://www.firebirdsql.org/file/documentation/release_notes/Firebird-3.0.0-ReleaseNotes.pdf - стр. 42.
12 май 16, 14:06    [19163741]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5959
чччД,

Спасибо, а то так далеко запрятали - я и в new features искал и в changes и в optimizations, а оно в new parameters
12 май 16, 14:44    [19163982]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
чччД
Guest
Имхо, с т.зр. требовательности к плотности сетевого трафика - FireBird не самый лучший выбор.
12 май 16, 16:31    [19164881]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
asphix
Member

Откуда: Петрозаводск
Сообщений: 52
почему-то субъективно склоняюсь к postgre..
12 май 16, 16:41    [19164952]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
Реляционную базу данных вообще бы не рекомендовал,
ибо реляционная модель не заточена на минимизацию трафика.

Тут варианта два,

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

либо документалка, способная прислать всю нужную информацию в одном джисоне.
12 май 16, 17:05    [19165174]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить