ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор СУБД для медленного канала
159 сообщений из 159, показаны все 7 страниц
  все  
Выбор СУБД для медленного канала
    #39233166
asphix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asphix
Гость
Доброго времени суток!

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

Изначально планируется клиент на Delphi. Вопрос в выборе СУБД (MySQL, PostgreSQL, etc..) и в выборе технологии коннекта (ADO, FireDAC, etc..)
...
Рейтинг: 0 / 0
11.05.2016, 11:51
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233196
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
asphixПосоветуйте что лучше использовать для реализации?
Проблема в том, что канал добавляет свою специфику. И одним выбором СУБД тут проблему не
решить. Нужен ещё программист, который эту специфику понимает и способен подогнать под неё
всю архитектуру приложения.

PS: MySQL бери, ему хуже уже не будет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.05.2016, 12:15
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233213
Sergey Orlov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Orlov
Участник
А базы с репликацией вы не рассматривали? впрочем, тут все зависит от специфики работы...
...
Рейтинг: 0 / 0
11.05.2016, 12:26
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233226
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
asphix,

Тут, имхо, дело не столько в СУБД, сколько в специфике написания запросов.
1) Никаких SELECT * FROM mytable, выбирать только нужные поля и только нужные записи.
2) Минимизировать количество запросов. Тут вариантов множество. Мне, например, приходилось сериализовать записи из detail-таблицы и соединять с мастер-таблицей, чтобы все данные выбрать за один запрос, а не терзать СУБД потом сотней маленьких запросов к detail-таблице. Не переоткрывать датасеты по каждом чиху и т.д. Возможно, что-то кэшировать локально (в датасетах или даже в файлах).
3) Пункт, противоположный пункту 1. Выбирать (например, при старте приложения) в датасет небольшие неизменяемые таблицы и потом фильтровать их локально, без повторных обращений.
...
Рейтинг: 0 / 0
11.05.2016, 12:38
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233309
asphix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asphix
Гость
miksoft, Спасибо за советы.

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

Sergey Orlov, репликацию рассматриваю, проблема лишь в том, что в клиентских сегментах нет возможности доп. базы развернуть, кроме, разве что, sqlite..
...
Рейтинг: 0 / 0
11.05.2016, 13:24
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233364
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
asphixкакие технологии (ADO, FireDAC, etc..) умеют кеширование в датасетах.Любые, где вообще есть датасеты или их аналоги. Под кэшированием понималось использование датасетов для этих целей, а не какие-то специфические механизмы в них.
...
Рейтинг: 0 / 0
11.05.2016, 13:55
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233380
Sergey Orlov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Orlov
Участник
asphixmiksoft, Спасибо за советы.
Осталось понять, какие технологии (ADO, FireDAC, etc..) умеют кеширование в датасетах.
Sergey Orlov, репликацию рассматриваю, проблема лишь в том, что в клиентских сегментах нет возможности доп. базы развернуть, кроме, разве что, sqlite..
А перейдите на веб, тогда вам пофиг будет канал, вам ведь не анимацию по нему гонять...
...
Рейтинг: 0 / 0
11.05.2016, 14:01
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233391
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Sergey OrlovА перейдите на веб, тогда вам пофиг будет канал, вам ведь не анимацию по нему гонять...Там тоже есть своя специфика.
Некоторые любят сотни КБ Javascript-a гонят :)
...
Рейтинг: 0 / 0
11.05.2016, 14:07
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233508
Sergey Orlov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Orlov
Участник
miksoftSergey OrlovА перейдите на веб, тогда вам пофиг будет канал, вам ведь не анимацию по нему гонять...Там тоже есть своя специфика.
Некоторые любят сотни КБ Javascript-a гонят :)
Программистов под php море... Хотя везде своя специфика...
Кстати если уже есть программа под Аксесс, то ее тоже можно юзать с SQL-сервером, доработав конечно...
...
Рейтинг: 0 / 0
11.05.2016, 15:49
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233569
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
asphixширина канала до сервера баз данных - (sic!) 128 кбит/с. Текущая поделка на Access 2007 безбожно тормозит. Посоветуйте что лучше использовать для реализации?
Кроме "ширины" канала, есть еще latency (задержка).

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

Как вариант можно попытаться рядом с сервером базы данных поднять терминальный сервер и запускать приложения на нем
...
Рейтинг: 0 / 0
11.05.2016, 16:46
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233602
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Кстати, без хранимых процедур не обойтись.
Из бесплатных - mysql отпадает сразу именно по этой причине.
...
Рейтинг: 0 / 0
11.05.2016, 17:27
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233605
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
ОКТОГЕНКстати, без хранимых процедур не обойтись.Это почему же?
ОКТОГЕНИз бесплатных - mysql отпадает сразу именно по этой причине.Почему?
В MySQL есть хранимые процедуры.
...
Рейтинг: 0 / 0
11.05.2016, 17:30
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233609
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
miksoftОКТОГЕНКстати, без хранимых процедур не обойтись.Это почему же?
ОКТОГЕНИз бесплатных - mysql отпадает сразу именно по этой причине.Почему?
В MySQL есть хранимые процедуры.
В хранимке очень удобно обрабатывать данные на сервере, не гоняя гигасы по сети.
В mysql по сравнению с другими СУБД их нет. Любой конкурент уделает мыскль на раз.
Та же птичка, к примеру.
...
Рейтинг: 0 / 0
11.05.2016, 17:33
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233617
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
ОКТОГЕНВ хранимке очень удобно обрабатывать данные на сервере, не гоняя гигасы по сети.Это можно делать и без хранимых процедур. Простой SQL запрос тоже может "обрабатывать данные на сервере, не гоняя гигасы по сети".
ОКТОГЕНВ mysql по сравнению с другими СУБД их нет. Любой конкурент уделает мыскль на раз.Обосновать можете?
...
Рейтинг: 0 / 0
11.05.2016, 17:37
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233618
leguo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
leguo
Гость
Господа.
Я может чего не понял, конечно. А терминалы здесь не помогут?
...
Рейтинг: 0 / 0
11.05.2016, 17:39
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233619
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ОКТОГЕНВ хранимке очень удобно обрабатывать данные на сервере, не гоняя гигасы по
сети.
То есть сначала кто-то, не подумав, загоняет необработанные данные в БД, а потом их там
обрабатывает, так?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.05.2016, 17:40
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233627
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
leguoЯ может чего не понял, конечно. А терминалы здесь не помогут?Зависит от того, сколько будет одновременных сессий. Если одна-две, то помогут. Три-четыре - будет сильно некомфортно работать. Если более, то, имхо, вряд ли реально.
Кроме того, непонятно, какие требования предъявляются к печати.
...
Рейтинг: 0 / 0
11.05.2016, 17:47
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233632
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
miksoftЭто можно делать и без хранимых процедур. Простой SQL запрос тоже может "обрабатывать данные на сервере, не гоняя гигасы по сети".
ОКТОГЕНВ mysql по сравнению с другими СУБД их нет. Любой конкурент уделает мыскль на раз.Обосновать можете?

miksoftЭто можно делать и без хранимых процедур. Простой SQL запрос тоже может "обрабатывать данные на сервере, не гоняя гигасы по сети".
Всё можно. Вопрос только в цене. То что вы на postgresql напишете за 10 минут,
вы часами отлаживать будете.
miksoftОбосновать можете?
Что тут обосновывать? То что у mysql
нет хранимок? Вы попробуйте хранимки того или иного сервера - поймёте.
Ничего там прикольного нет, только ежли себя наказать не хотите.
Там даже транзакций нормальных нет. Про репликацию не говрю.
Если вам понадобятся нестандартные вещи - намаетесь, т.к. функционал по движкам размазан.
...
Рейтинг: 0 / 0
11.05.2016, 17:50
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233640
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Dimitry SibiryakovТо есть сначала кто-то, не подумав, загоняет необработанные данные в БД, а потом их там
обрабатывает, так?..

Даже отчёты разные бывают.
Например, сжатый график из данных вытащить.
В этом классе задач не всегда один селект всё решит.
...
Рейтинг: 0 / 0
11.05.2016, 17:54
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233641
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
ОКТОГЕНВсё можно. Вопрос только в цене. То что вы на postgresql напишете за 10 минут,
вы часами отлаживать будете.А причем тут отладка (хотя и про нее неверно)?
Изначальный Ваш тезис был "не обойтись".
ОКТОГЕНЧто тут обосновывать? То что у mysql
нет хранимок? Вы попробуйте хранимки того или иного сервера - поймёте.Пробовал не однократно. Для меня основная рабочая СУБД Оракл. Конечно, там возможности хранимок побогаче. Но не настолько, чтобы говорить, что в MySQL их нет.

В MySQL нет анонимных процедур, но это почти полностью компенсируется тем, что там есть пользовательские переменные сессионного уровня.
ОКТОГЕНТам даже транзакций нормальных нет.Есть.
ОКТОГЕНПро репликацию не говрю.Репликации со своими особенностями, но тоже есть.
ОКТОГЕНЕсли вам понадобятся нестандартные вещи - намаетесьЭто в любой СУБД так - как только понадобятся нестандартные для это СУБД вещи - намаетесь. Т.е. это тоже не аргумент.
ОКТОГЕНфункционал по движкам размазан.Сейчас это не имеет сильного практического значения, т.к. по факту используется только один движок - InnoDB (или его потомки в форках).
...
Рейтинг: 0 / 0
11.05.2016, 17:59
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233643
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
ОКТОГЕНДаже отчёты разные бывают.
Например, сжатый график из данных вытащить.
В этом классе задач не всегда один селект всё решит.В ряде случаев - да, хранимые процедуры сильно помогают. Но из этого никак не следует, что без них не обойтись.
...
Рейтинг: 0 / 0
11.05.2016, 18:01
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233649
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
miksoft,

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

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

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

С остальным мириться можно, даже не совсем стандартным SQL.
...
Рейтинг: 0 / 0
11.05.2016, 18:09
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233665
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
miksoft В ряде случаев - да, хранимые процедуры сильно помогают. Но из этого никак не следует, что без них не обойтись.
А зачем без них обходиться, если можно не обходиться?
Тем более что и по лицензиям mysql как минимум - конкуренты ей не уступают.
Автор темы вообще может всю логику обработки на SQL сервер вытащить,
а в качестве клиента тот же либр офис задолбить. Да и майкрософт можно оставить.
Чисто как оболочку для вызова хранимок.
Поставить одбц и погнали. Почему нет?
...
Рейтинг: 0 / 0
11.05.2016, 18:24
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233668
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Симонов Денис1. Возврат набора данных через временные таблицы это извращениеЕсли возврат на клиента, то процедура может сама возвращать набор записей. И даже несколько наборов.

В целом - да, таковые недостатки есть.
Но имеют ли они существенное значение в задаче топикстартера - не уверен. Тут уже недостаточно информации от него.
...
Рейтинг: 0 / 0
11.05.2016, 18:25
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233683
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
asphix,
ставь на отдельную машину SQL - птичку,постгрес,
на какой-нить клиент ставь либы, пробуй к ним из акцесса постучаться.
Получится - вытаскивай обработку и хранение на SQL
...
Рейтинг: 0 / 0
11.05.2016, 18:36
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233746
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
asphixДоброго времени суток!

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

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

Любоая клиент-серверная СУБД, плюс -- прямые руки.
Технологии коннекта любые, они все некритически различаются, грубо говоря, все одинаковые.
...
Рейтинг: 0 / 0
11.05.2016, 20:20
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233748
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
ОКТОГЕНmiksoftпропущено...
Это почему же?
пропущено...
Почему?
В MySQL есть хранимые процедуры.
В хранимке очень удобно обрабатывать данные на сервере, не гоняя гигасы по сети.
В mysql по сравнению с другими СУБД их нет. Любой конкурент уделает мыскль на раз.
Та же птичка, к примеру.

В MYSQL есть процедуры. Работают. Вполне сносный язык.
Есть проблемы, но на новой разработке можно использовать последнюю версию MySQL, где всё более-менее починино.
...
Рейтинг: 0 / 0
11.05.2016, 20:23
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233749
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
лично мне в процедурном языке mysql неудобно многое
1. Возврат набора данных через временные таблицы это извращение


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



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

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


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


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

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


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

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

Ну да, mySQL не лучшая субд, но всё же не такая уж и плохая.
...
Рейтинг: 0 / 0
11.05.2016, 20:26
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233827
AndrF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AndrF
Участник
В определенных случаях логичней заюзать терминалы - трафик при этом я бы не сказал что большой.
...
Рейтинг: 0 / 0
11.05.2016, 23:22
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39233973
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
MasterZiv1. Возврат набора данных через временные таблицы это извращение

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


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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
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 не лучшая субд, но всё же не такая уж и плохая.

Кто спорит. Работать можно и работаем. Но раз уж речь зашла о процедурах, то по сравнению со многими другими СУБД тут всё плохо.
...
Рейтинг: 0 / 0
12.05.2016, 09:37
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234032
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Симонов ДенисВ MySql ту последовательность от 1 до 10 мне бы пришлось сначала положить в таблицу а потом делать из неё SELECT внутри процедуры.Для этого можно использовать любую имеющуюся таблицу. Да и таблица dual никуда не делась, хотя через нее неудобно.
Симонов ДенисА вот как использовать набор данных возвращаемой процедурой внутри другой процедуры?Тут, увы, никак. Прямой возврат возможен только на клиента.
...
Рейтинг: 0 / 0
12.05.2016, 10:28
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234092
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
Симонов Денис[Допустим мне надо получить последовательность чисел от 1 до 10. На FB это выглядело бы следующим образом

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
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)
...
Рейтинг: 0 / 0
12.05.2016, 11:18
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234136
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Ivan Durak,

то что PG для этого придумал встроенную функцию это понятно. Вопрос был не конкретно в генераторе чисел от 1 до 10. Это лишь пример когда процедура должна генерировать данные, которые не получаются из запроса. Алгоритм то может быть сложнее и совсем другой
...
Рейтинг: 0 / 0
12.05.2016, 11:41
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234141
dvim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dvim
Участник
asphix,
-какие требования по работе приложения при пропадании канала.
на минуту/час /день?
-общий объем данных

От этого очень зависит логика.
...
Рейтинг: 0 / 0
12.05.2016, 11:44
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234188
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Нужно создавать локальные (региональные) БД и реплицировать по возможности.

Вообще странное это ограничение... на телефонных модемах там сидите штоли... ?
...
Рейтинг: 0 / 0
12.05.2016, 12:14
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234261
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Участник
Кстати, оракл сжимает трафик sql*net, остальные рсубд тоже? Какие сжимают, какие - нет?
...
Рейтинг: 0 / 0
12.05.2016, 13:19
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234268
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Участник
Беглый поиск дал: mssql server умеет сжимать только между своими инстансами, к клиенту не умеет; postgresql умеет только через openssl с какой-то версии, т.е. нужен именно ssl коннект. Что с остальными?
...
Рейтинг: 0 / 0
12.05.2016, 13:27
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234270
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
xtenderКстати, оракл сжимает трафик sql*net, остальные рсубд тоже? Какие сжимают, какие - нет?

Firebird 3.0 по умолчанию не сжимает, но это можно включить.
По умолчанию не сжимает потому что в ЛВС это не имеет смысла, затраты на сжатие перекроют выигрыш от него.
...
Рейтинг: 0 / 0
12.05.2016, 13:29
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234275
asphix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asphix
Гость
dvim, при пропадании канала всех собак вешают на сетевиков головного офиса и простой не критичен совсем. На это можно не ориентироваться.
...
Рейтинг: 0 / 0
12.05.2016, 13:36
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234294
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
xtenderЧто с остальными?
Firebird 3 сжимает zlib. Но против высокой латентности канала это бесполезно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
12.05.2016, 13:56
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234300
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Участник
Симонов Денис,

глянул мельком - правильно я понимаю, что еще не зарелизили? это только в 3.0 RC2 пока?
...
Рейтинг: 0 / 0
12.05.2016, 14:00
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234304
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
xtender,

куда то ты не туда смотришь. Релиз вышел 19 апреля.
http://www.firebirdsql.org/en/news/firebird-3-0-is-released/
...
Рейтинг: 0 / 0
12.05.2016, 14:01
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234305
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Участник
Dimitry Sibiryakov,

http://web.firebirdsql.org/download/prerelease/rlsnotes/Firebird-3.0.0_RC2-ReleaseNotes.pdf
только в RC2?
...
Рейтинг: 0 / 0
12.05.2016, 14:01
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234307
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
xtender,

http://www.firebirdsql.org/en/firebird-3-0-0/
...
Рейтинг: 0 / 0
12.05.2016, 14:02
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234308
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Участник
Симонов Денис,

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
...
Рейтинг: 0 / 0
12.05.2016, 14:02
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234313
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
чччД
Участник
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.
...
Рейтинг: 0 / 0
12.05.2016, 14:06
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234357
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Участник
чччД,

Спасибо, а то так далеко запрятали - я и в new features искал и в changes и в optimizations, а оно в new parameters
...
Рейтинг: 0 / 0
12.05.2016, 14:44
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234469
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
чччД
Участник
Имхо, с т.зр. требовательности к плотности сетевого трафика - FireBird не самый лучший выбор.
...
Рейтинг: 0 / 0
12.05.2016, 16:31
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234479
asphix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asphix
Гость
почему-то субъективно склоняюсь к postgre..
...
Рейтинг: 0 / 0
12.05.2016, 16:41
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234508
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
Реляционную базу данных вообще бы не рекомендовал,
ибо реляционная модель не заточена на минимизацию трафика.

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

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

либо документалка, способная прислать всю нужную информацию в одном джисоне.
...
Рейтинг: 0 / 0
12.05.2016, 17:05
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234514
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
stopв одном джисоне.Который тоже не очень-то "заточен на минимизацию трафика" :)
...
Рейтинг: 0 / 0
12.05.2016, 17:08
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234518
20 шт
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
20 шт
Участник
miksoftstopв одном джисоне.Который тоже не очень-то "заточен на минимизацию трафика" :)
В зазипованном джисоне! :)
...
Рейтинг: 0 / 0
12.05.2016, 17:14
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234531
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
20 штВ зазипованном джисоне! :)Это можно и к СУБД сжатие трафика прикрутить. Тот же OpenVPN умеет. А специализированные решения жмут еще лучше, хотя изрядно дорогие.
...
Рейтинг: 0 / 0
12.05.2016, 17:21
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234535
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
miksoft,

Как сказал Дмитрий против высокой латентности канала это бесполезно.
...
Рейтинг: 0 / 0
12.05.2016, 17:24
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234548
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Симонов Денисmiksoft,

Как сказал Дмитрий против высокой латентности канала это бесполезно.Это понятно, против нее все бесполезно, если передавать через канал интерактивные данные. В т.ч. и "джисон".
...
Рейтинг: 0 / 0
12.05.2016, 17:29
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234626
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
miksoftСимонов Денисmiksoft,

Как сказал Дмитрий против высокой латентности канала это бесполезно.Это понятно, против нее все бесполезно, если передавать через канал интерактивные данные. В т.ч. и "джисон".

Ну если вы будете на стороне базы данных из таблиц собирать джисоны, то может чтото и получится.

Про Джисон я сказал, потому что Иерархия явно лучше минимизирует и представляет данные для передачи по сети,
в отличии от типизированых таблицы с их датасетами.

Пакет с джисончиком для Днипры может состоять всего из нескольких байт и делать какойто мелкий апдейт.
Селект пользователя из базы, (симбиоз данных из примерно 20 таблиц еслиб они были в таблицах) занимает 2.3 кб.
...
Рейтинг: 0 / 0
12.05.2016, 18:54
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234640
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
stop, привет как сам?
...
Рейтинг: 0 / 0
12.05.2016, 19:24
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234681
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
maytonstop, привет как сам?

Привет, норм.
Пилю по мере возмжностей крупный проект на Днипре, вычищаю баги.
У тебя как справы ?
...
Рейтинг: 0 / 0
12.05.2016, 21:02
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234685
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
asphixТекущая поделка на Access 2007

Значит база < 2Gb. Посмотрите в сторону MS SQL Server 2014 Express Edition. И переход будет проще, и доп. нишнтяков поимеете (Reporting, FTS). Переносите по максимуму обработку данных на серверную сторону (хп). Клиент может остаться и на дельфе, хотя, его все равно придеться переписывать. Компоненты доступа к данным в принципе без разницы какие (если клиент будет дергать хп с сервера), лишь бы они вас устраивали по уровню совместимости с версией сервера в части поддерживаемых нововведений. Кстати, дельфа то какая?
...
Рейтинг: 0 / 0
12.05.2016, 21:26
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234688
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stopПро Джисон я сказал, потому что Иерархия явно лучше минимизирует и представляет данные для передачи по сети,
в отличии от типизированых таблицы с их датасетами.

Пакет с джисончиком для Днипры может состоять всего из нескольких байт и делать какойто мелкий апдейт.
Селект пользователя из базы, (симбиоз данных из примерно 20 таблиц еслиб они были в таблицах) занимает 2.3 кб.

Гм... Каким образом минимизирует? Зачем передавать всю иерархию по сети? Ну, вот классическое дерево. Пусть там на листьевом уровне будет 1 000 000 элементов. Показали пользователю первый уровень, состоящий, ну, скажем, из 10 узлов, показав признак наличия "детей" плюсиком, там где есть дети. Запросик будет простой, результат плоский, трафик минимальный. Будет пользователь кликать по плюсикам, будем подтягивать данные, выполняя все тот же самый серверный код.

Вы готовы заранее предугадать, какой плюсик кликнет пользователь, чтобы тащить нужный кусок иерархии? Или не доводилось работать с большим кол-вом детей? Это не сраказм и не наезд. Просто пытаюсь понять, как джисон мне сможет здесь помочь, заменив точеченые обращения к бд с получением результата в TDS.
...
Рейтинг: 0 / 0
12.05.2016, 21:36
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234691
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
miksoftА специализированные решения жмут еще лучше, хотя изрядно дорогие.

Сложно говорить о дорогих специализированных решениях, когда заявленный автором канал - 128 КБит. Кстати, интересно, какой он в смысле физики...
...
Рейтинг: 0 / 0
12.05.2016, 21:51
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234695
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstopПро Джисон я сказал, потому что Иерархия явно лучше минимизирует и представляет данные для передачи по сети,
в отличии от типизированых таблицы с их датасетами.

Пакет с джисончиком для Днипры может состоять всего из нескольких байт и делать какойто мелкий апдейт.
Селект пользователя из базы, (симбиоз данных из примерно 20 таблиц еслиб они были в таблицах) занимает 2.3 кб.

Гм... Каким образом минимизирует? Зачем передавать всю иерархию по сети? Ну, вот классическое дерево. Пусть там на листьевом уровне будет 1 000 000 элементов. Показали пользователю первый уровень, состоящий, ну, скажем, из 10 узлов, показав признак наличия "детей" плюсиком, там где есть дети. Запросик будет простой, результат плоский, трафик минимальный. Будет пользователь кликать по плюсикам, будем подтягивать данные, выполняя все тот же самый серверный код.

Вы готовы заранее предугадать, какой плюсик кликнет пользователь, чтобы тащить нужный кусок иерархии? Или не доводилось работать с большим кол-вом детей? Это не сраказм и не наезд. Просто пытаюсь понять, как джисон мне сможет здесь помочь, заменив точеченые обращения к бд с получением результата в TDS.

Вы не совсем поняли суть того, о чем я говорил.
Если в джисоне (иерархии) можно представить обьект вот так,
и вернуть его за один запрос

Код: c#
1.
2.
3.
4.
{
type:'type',
members:[1,2,3,4,5,6,7,8,9.10]
}



То в реляционке все делается через джоин
membertype1type2type3type4type5type6type7type8type9type10type

Конечно, можно попытаться сделать два запроса (опять же трафик и латентность канала).
Может быть чтото попытается сжать сам провайдер RDBMS, но суть остается сутью.
...
Рейтинг: 0 / 0
12.05.2016, 22:01
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234697
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
Ну и разница в размере пакета, даже на таком простом примере уже в 2 раза.
Плюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах,
плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон.
...
Рейтинг: 0 / 0
12.05.2016, 22:09
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234701
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
pkarklinКстати, интересно, какой он в смысле физики...С обоих (со всех, если их больше двух) концов канала стоит специальная железяка. Она умеет обучаться по проходящему трафику и накапливать статистику, по которой составляется частотный словарь для пакетов. При дальнейшей работе, когда нужно передать уже переданный ранее пакет (или данные прикладного протокола), передается только его номер по словарю. Железяки умеют работать как на уровне TCP/IP, так и на уровне ряда прикладных протоколов (в т.ч. SMB). Понимают ли они протоколы СУБД - не знаю. Естественно, пускать шифрованный VPN поверх такого канала неэффективно, ибо почти всегда будут промахи мимо словаря.
...
Рейтинг: 0 / 0
12.05.2016, 22:11
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234702
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

авторТо в реляционке все делается через джоин

Ах, вон Вы про что. Это сгодится, когда количество type ограничено десятками. В этом случае для лукапа выполнить один отдельный запрос. Если кол-во значений в type будет большим, как будет это выглядеть?
...
Рейтинг: 0 / 0
12.05.2016, 22:12
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234703
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
miksoftpkarklinКстати, интересно, какой он в смысле физики...С обоих (со всех, если их больше двух) концов канала стоит специальная железяка. Она умеет обучаться по проходящему трафику и накапливать статистику, по которой составляется частотный словарь для пакетов. При дальнейшей работе, когда нужно передать уже переданный ранее пакет (или данные прикладного протокола), передается только его номер по словарю. Железяки умеют работать как на уровне TCP/IP, так и на уровне ряда прикладных протоколов (в т.ч. SMB). Понимают ли они протоколы СУБД - не знаю. Естественно, пускать шифрованный VPN поверх такого канала неэффективно, ибо почти всегда будут промахи мимо словаря.

Прошу прощения, что я не правильно выразился и Вы меня неправильно поняли. Про физику я спрашивал в плане канала у ТС, а не о "специальных железяках".
...
Рейтинг: 0 / 0
12.05.2016, 22:15
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234704
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
stopЕсли в джисоне (иерархии) можно представить обьект вот так,
и вернуть его за один запрос

Код: c#
1.
2.
3.
4.
{
type:'type',
members:[1,2,3,4,5,6,7,8,9.10]
}




То в реляционке все делается через джоин
membertype1type2type3type4type5type6type7type8type9type10typeВ SQL тоже можно сериализовать (в т.ч. частично) результат и получить такую выборку:
memberstype1,2,3,4,5,6,7,8,9,10type
...
Рейтинг: 0 / 0
12.05.2016, 22:16
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234708
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stopНу и разница в размере пакета, даже на таком простом примере уже в 2 раза.

4K - это дефолтный размер пакета, который можно уменьшить до 512 для систем, неиспользующих bulk операции и обменивающимися малыми порциями данных. Ну, или увеличить до 16,383.

stopПлюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах,
плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон.

Это легко можно проверить, в части размера трафика. Передача метаданных с данными - это одна из полезных фич, ибо понять без метаданных, что такое 20160512 невозможно.
...
Рейтинг: 0 / 0
12.05.2016, 22:20
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234710
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,

авторТо в реляционке все делается через джоин

Ах, вон Вы про что. Это сгодится, когда количество type ограничено десятками. В этом случае для лукапа выполнить один отдельный запрос. Если кол-во значений в type будет большим, как будет это выглядеть?

А как будет выглядеть таблица, если джоинов будет не один, а допустим с 10-15 таблицами
что ближе к реальности ?

Вот например, мой джисончик сущности User

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
private Widget CreateTestWidget()
        {
            return new Widget()
            {
                Author = new Author()
                {
                    IsPrivate = false,
                    Login = "Bob",
                    CreatedOn = DateTime.Now,
                    Likes = new List<Like>()
                                    {
                                        new Like()
                                        {
                                            Login = "Mary",
                                            OnDate = DateTime.Now
                                        }
                                    }

                },

                Name = "Widget",
                Description = "Widget Description",
                Picture = null,
                Comments = new List<Message>()
                                {
                                    new Message()
                                    {
                                        Author = new Author()
                                        {
                                            IsPrivate = false,
                                            Login = "Bob",
                                            CreatedOn = DateTime.Now,
                                            Likes = new List<Like>()
                                            {
                                                new Like()
                                                {
                                                    Login = "Mary",
                                                    OnDate = DateTime.Now
                                                }
                                            }
                                        },

                                        Text = null
                                    }
                                },

                Period = new Period()
                {
                    FromDate = DateTime.Now,
                    ToDate = DateTime.Now,

                    Type = "Month"
                },

                LasDocID = 10,

                Source = new Source()
                {
                    Type = "All",
                    Names = null
                },

                Conditions = new List<Condition>()
                                {
                                    new Condition()
                                    {
                                        OnlyTitle = false,
                                        Phrase = "phrase",
                                        Words = null,
                                        MinWords = 1,
                                        UseStemming = true
                                    }
                                },

                Output = new Output()
                {
                    Type = "Text"
                },

                Notifications = new List<Notification>()
                                {
                                    new Notification()
                                    {
                                        Type = "Email",
                                        Address = "bob@mail.com"
                                    }
                                },

                Price = new Price()
                {
                    Value = 10
                },

                LikedItems = new List<Item>()
                                {
                                    new Item()
                                    {
                                        Title = "Item title",
                                        URL = "Item URL",
                                        Text = "Item Text"
                                    }
                                }
            };
        }

        private User CreateTestUser()
        {
            User user = new User()
            {
                Author = new Author()
                {
                    IsPrivate = false,
                    Login = "Bob",
                    CreatedOn = DateTime.Now,
                    Likes = new List<Like>()
                    {
                        new Like()
                        {
                            Login = "Mary",
                            OnDate = DateTime.Now
                        }
                    }
                },

                Login = "Bob",
                Password = "test",
                From = "UA",
                Email = "bob@mail.ru",
                Picture = null,
                Age = 20,
                Interests = "Searching",

                Pages = new List<Page>()
                {
                    new Page()
                    {
                        Name = "Bob Page",
                        Description = "Bob Page Description",
                        Author = new Author()
                        {
                            IsPrivate = false,
                            Login = "Bob",
                            CreatedOn = DateTime.Now,
                            Likes = new List<Like>()
                            {
                                new Like()
                                {
                                    Login = "Mary",
                                    OnDate = DateTime.Now
                                }
                            }
                        },

                        Widgets = new List<Widget>()
                        {
                            CreateTestWidget(),
                            CreateTestWidget()
                        }
                    }
                },

                Favourits = new List<Item>()
                {
                    new Item()
                    {
                        Title = "Item title",
                        URL = "Item URL",
                        Text = "Item Text"
                    }
                },

                Libraries = new List<Library>()
                {
                    new Library()
                    {
                        Author = new Author()
                        {
                           IsPrivate = false,
                           Login = "Bob",
                           Likes = new List<Like>()
                           {
                                new Like()
                                {
                                    Login = "Mary",
                                    OnDate = DateTime.Now
                                }
                           },
                           CreatedOn = DateTime.Now
                        },

                        Category = "Library Category",
                        SubCategory = "Library SubCategory",

                        Name = "Name",
                        Descritpion = null,

                        Words = null,

                        ApproveWords = new List<ApproveWords>()
                        {
                            new ApproveWords()
                            {
                                Author = new Author()
                                {
                                    IsPrivate = false,
                                    Login = "Bob",
                                    CreatedOn = DateTime.Now
                                },

                                Words = null
                            }
                        }
                    }
                },

                BanList = new List<Author>()
                {
                    new Author()
                    {
                        IsPrivate = false,
                        Login = "Bob",
                        CreatedOn = DateTime.Now
                    }
                },

                Inbox = new List<Message>()
                {
                    new Message()
                    {
                        Author = new Author()
                        {
                            IsPrivate = false,
                            Login = "Bob",
                            CreatedOn = DateTime.Now,
                            Likes = new List<Like>()
                            {
                                new Like()
                                {
                                    Login = "Mary",
                                    OnDate = DateTime.Now
                                }
                            }
                        },

                        Text = null
                    }
                },

                Outbox = new List<Message>()
                {
                    new Message()
                    {
                        Author = new Author()
                        {
                            IsPrivate = false,
                            Login = "Bob",
                            CreatedOn = DateTime.Now,
                            Likes = new List<Like>()
                            {
                                new Like()
                                {
                                    Login = "Mary",
                                    OnDate = DateTime.Now
                                }
                            }
                        },

                        Text = null
                    }
                }
            };

            return user;

        }



Здесь гдето 2-3 кб данных если сериализовать.
Как это через таблицы вытянуть, какой трафик будет ?
Или опять на запросы дробить, что еще более смертельно для слабых каналов связи.
...
Рейтинг: 0 / 0
12.05.2016, 22:21
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234714
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Участник
stop,

Сериализовывать в json сейчас все умеют...
...
Рейтинг: 0 / 0
12.05.2016, 22:25
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234715
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
stopПлюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах,
плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон."Джисон" тоже не по голому TCP/IP обычно передается. Т.е. тоже HTTP-оверхэд присутствует.
...
Рейтинг: 0 / 0
12.05.2016, 22:28
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234716
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

авторА как будет выглядеть таблица, если джоинов будет не один, а допустим с 10-15 таблицами
что ближе к реальности ?

10-15 справочников в одном выносе? В части BI в плане звезды я еще могу представить такое. В транзакционной системе - нет.

авторВот например, мой джисончик сущности User

Много как-то букв. Если Вы по-русски опищите, что он делает, то я по возможности постараюсь оценить объем трафика. С Вас физическая модель данных только.
...
Рейтинг: 0 / 0
12.05.2016, 22:29
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234718
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,

авторА как будет выглядеть таблица, если джоинов будет не один, а допустим с 10-15 таблицами
что ближе к реальности ?

10-15 справочников в одном выносе? В части BI в плане звезды я еще могу представить такое. В транзакционной системе - нет.


Открытие даже какой нибудь самой простой учетной системы генерит обращение к десяткам таблиц уже при просто ее открытии.
В самой базе же могут быть сотни таблиц.

pkarklinМного как-то букв. Если Вы по-русски опищите, что он делает, то я по возможности постараюсь оценить объем трафика. С Вас физическая модель данных только.

Там не на русском, там на С# готовая модель данных, которую можно запихнуть в какую нибудь ORM и оценить количество сгенерированых таблиц а также размер трафика, когда эту модельку нужно натянуть на вьюшку.
...
Рейтинг: 0 / 0
12.05.2016, 22:38
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234719
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

И я, к сожалению, не получил ответа на этот вопрос:

авторЕсли кол-во значений в type будет большим, как будет это выглядеть?
...
Рейтинг: 0 / 0
12.05.2016, 22:39
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234720
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
miksoftstopПлюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах,
плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон."Джисон" тоже не по голому TCP/IP обычно передается. Т.е. тоже HTTP-оверхэд присутствует.

Смотря где.
В мой СУБД джисон пишется прямо в сокет, следовательно оверхед там считаные байты.
...
Рейтинг: 0 / 0
12.05.2016, 22:40
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234721
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

авторОткрытие даже какой нибудь самой простой учетной системы генерит обращение к десяткам таблиц уже при просто ее открытии.
В самой базе же могут быть сотни таблиц.

Вы откуда об этом знаете? А если таблиц в базе тыщи? Какие выводы из этого можно сделать?

авторТам не на русском, там на С# готовая модель данных, которую можно запихнуть в какую нибудь ORM и оценить количество сгенерированых таблиц а также размер трафика, когда эту модельку нужно натянуть на вьюшку .

Всё, понятно, дальше можете не продолжать...
...
Рейтинг: 0 / 0
12.05.2016, 22:42
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234723
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Сегодня мы прослушали очередное выступлени мемебра, который с данными работать не умеет. Возможно, он знает C#. Этот, как его, джисон. Ну, и ORM, какой-нибудь, не к ночи будь помянут.
...
Рейтинг: 0 / 0
12.05.2016, 22:45
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234724
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,

И я, к сожалению, не получил ответа на этот вопрос:

авторЕсли кол-во значений в type будет большим, как будет это выглядеть?

Может быть както так
Код: c#
1.
2.
3.
4.
5.
[
   {type:car, doc:{model:zaz,engine:1.2}},
   {type:employee, doc:{fname:ivan,lname:ivanov}},
   {type:author, doc:{author:shevchenko}},
]



А в таблицах это как будет ?
...
Рейтинг: 0 / 0
12.05.2016, 22:45
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234726
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

Там слово было ключевое - "большим".
...
Рейтинг: 0 / 0
12.05.2016, 22:47
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234727
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinСегодня мы прослушали очередное выступлени мемебра, который с данными работать не умеет. Возможно, он знает C#. Этот, как его, джисон. Ну, и ORM, какой-нибудь, не к ночи будь помянут.

Не нервничай "специалист".
Я всеголишь вам наглядно показал, почему джисон и документоориентированые базы куда оптимальнее гоняют трафик.
...
Рейтинг: 0 / 0
12.05.2016, 22:47
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234729
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stopЯ всеголишь вам наглядно показал, почему джисон и документоориентированые базы куда оптимальнее гоняют трафик.

Пока ты ничего не показал. Ибо то, что ты показал - это уровень Hello, Word!
...
Рейтинг: 0 / 0
12.05.2016, 22:48
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234730
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,

Там слово было ключевое - "большим".

А здесь "маленьким" ?
Мне лень рисовать массив обьектов, можешь продолжать его до бесконечности,
типы не повторяются.
...
Рейтинг: 0 / 0
12.05.2016, 22:49
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234732
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stopА здесь "маленьким" ?
Да.
stopМне лень...

Я ничуть в этом не сомневался...
...
Рейтинг: 0 / 0
12.05.2016, 22:50
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234735
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstopЯ всеголишь вам наглядно показал, почему джисон и документоориентированые базы куда оптимальнее гоняют трафик.

Пока ты ничего не показал. Ибо то, что ты показал - это уровень Hello, Word!

Это не Вам адресовывалось. А тем кто понимает то, о чем я пишу.
Согласно Вашему уровню, могу предложить вот этот инструмент



Чтобы сделать соотвествующие замеры
Удачи.
...
Рейтинг: 0 / 0
12.05.2016, 22:53
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234737
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stopА тем кто понимает то, о чем я пишу
Тут таких нет.
stopСогласно Вашему уровню, могу предложить вот этот инструмент
Чтобы сделать соотвествующие замеры
Премного благодарен. Таких эпических сливов давно не видовал.
stopУдачи.
Я, уж, как-нибудь сам, без Ваших пожеланий...
...
Рейтинг: 0 / 0
12.05.2016, 22:56
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234738
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
Ты сначала перепиши мой "Хелоу Ворд" на 20 таблиц,
сходи померяй трафик, а потом будешь выяснять кто слился.

Как по мне, то даже школьникам должно быть понятно, что schemaless структуры данных куда эффективней гоняют трафик.
Особенно после трех моих приведенных примеров и ниодного твоего. Ну видать разные школьники бывают.
...
Рейтинг: 0 / 0
12.05.2016, 23:07
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234739
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

авторТы сначала перепиши мой "Хелоу Ворд" на 20 таблиц,
Я спрашивал про физическую модель данных. Где ответ?
авторсходи померяй трафик, а потом будешь выяснять кто слился.
Я предлагал его померять. Где примеры тестовых данных в контексте физической модели?
авторКак по мне, то даже школьникам должно быть понятно...
Это, безусловно самый неопроверживый аргумент!
авторчто schemaless структуры данных куда эффективней гоняют трафик.
А замеры трафика то где? В реальных системах, а не в Hello, World! Какие последствия в разработке и поддержке, что они schemaless? Где оценки этих рисков? Их нет. Ибо об этом не думается, когда решается сугубо неприкладная задача.
авторОсобенно после трех моих приведенных примеров и ниодного твоего.
Мерянье трафика в постах на форуме. Ржал в голос...
авторНу видать разные школьники бывают.
Одного я точно давно уже знаю...
...
Рейтинг: 0 / 0
12.05.2016, 23:16
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234742
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,
Я спрашивал про физическую модель данных. Где ответ?


Открой для себя что такое анонимные классы.
Приведенного моего примера вполне достаточно чтобы инстанциировать всю иерархию классов.

pkarklinstop,
Я предлагал его померять. Где примеры тестовых данных в контексте физической модели?


Модель данных у тебя есть. Понимаю что ты ожидал увидеть "удобные" для себя табличные данные,
но к сожалению нас окружают иерархии, а не таблицы со связями.

pkarklinstop,
А замеры трафика то где?


Читай первый пост этой темы.
Автор пишет что в Access на слабом канале все тормозит.
Неужели ты думаешь что замена на MS SQL, одной реляционной базы на другую, даст хоть какойто прирост производительности
на слабом канале ?

pkarklinstop,
В реальных системах, а не в Hello, World! Какие последствия в разработке и поддержке, что они
schemaless? Где оценки этих рисков? Их нет. Ибо об этом не думается, когда решается сугубо неприкладная задача.


А это уже другая задача. Тут задача решается в рамках минимизации трафика.

pkarklinstop,
Мерянье трафика в постах на форуме. Ржал в голос...
Одного я точно давно уже знаю...

Лол. Если в моем джисон документе количество описаных сущностей выростит до 1000 или 2000,
то он все еще будет пригоден чтобы его гоняли на слабом трафике.
Стоит ли говорить что RDBMS с 1000 таблиц превращается в неуправляемое мессиво полу NoSQLного кода,
с тысячами строк в каждой процедуре чтобы это все разложить по иерархиям, апдейтить и поддерживать.
Сам такое наблюдал в проекте и не раз. Потому, уж поверь.
...
Рейтинг: 0 / 0
12.05.2016, 23:25
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234743
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
stopmaytonstop, привет как сам?

Привет, норм.
Пилю по мере возмжностей крупный проект на Днипре, вычищаю баги.
У тебя как справы ?
Придавил проект. Сил хватает только на флуд. Никакого анализа и кодинга не осилю пока.
Вечером сижу еле мышкой шевелю. Может ближе к лету взгляну снова на твой BDSM DBMS
...
Рейтинг: 0 / 0
12.05.2016, 23:27
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234745
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
maytonstopпропущено...


Привет, норм.
Пилю по мере возмжностей крупный проект на Днипре, вычищаю баги.
У тебя как справы ?
Придавил проект. Сил хватает только на флуд. Никакого анализа и кодинга не осилю пока.
Вечером сижу еле мышкой шевелю. Может ближе к лету взгляну снова на твой BDSM DBMS

Ок, пиши когда освободишся.
Есть много интересного.
...
Рейтинг: 0 / 0
12.05.2016, 23:30
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234747
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

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

авторНеужели ты думаешь что замена на MS SQL, одной реляционной базы на другую, даст хоть какойто прирост производительности
на слабом канале ?

Access - файл-серверная СУБД. Про MS SQL, полагаю не надо ничего объяснять...

Когда будешь готов к какому-либо техническому мерянию (если нужно, под твои поделки поднимем необходимое число виртуалок, ты только требования к CPU, IOPs и пропусконой способности сети скажи, чтоб мы сумели это все зарезать) - приходи...
...
Рейтинг: 0 / 0
12.05.2016, 23:38
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234749
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,
Ты много всякой словесно пурги написал. При этом ни одной технической детали. Я даже меряться предлагал.


Ну так я же тебе уже дал ориентир как поступить.
Берешь мою иерархию 19166762 , запихиваешь ее в ОРМ (можешь и сам таблицы педалить, но мне кажется это жестоко даже для тебя). Потом берешь вытягиваешь ровно все эти данные с базы данных через АДО (или любую другу приблуду)
на клиент и замеряешь трафик.

pkarklinstop,
Access - файл-серверная СУБД. Про MS SQL, полагаю не надо ничего объяснять...
Когда будешь готов к какому-либо техническому мерянию (если нужно, под твои поделки поднимем необходимое число виртуалок, ты только требования к CPU, IOPs и пропусконой способности сети скажи, чтоб мы сумели это все зарезать) - приходи...

Угу, только Access писали в 90х, когда у всех на машинах трафик был даже не 128 кбит,
а 56кбит и через телефонный модем. А MS SQL серьезная промышленная база данных, со всеми вытекающими оверхедами.
...
Рейтинг: 0 / 0
12.05.2016, 23:48
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234750
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
stopСтоит ли говорить что RDBMS с 1000 таблиц превращается в неуправляемое мессиво полу NoSQLного кода,Забавно, этот топик собрал уже много излишне категоричных фраз.

У нас в корпоративной БД количество таблиц уже давно измеряется тысячами. Однако ни в какое месиво она пока не превратилась (и, уж тем более, в месиво "полу NoSQLного кода").
...
Рейтинг: 0 / 0
12.05.2016, 23:51
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234752
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
miksoftstopСтоит ли говорить что RDBMS с 1000 таблиц превращается в неуправляемое мессиво полу NoSQLного кода,Забавно, этот топик собрал уже много излишне категоричных фраз.

У нас в корпоративной БД количество таблиц уже давно измеряется тысячами. Однако ни в какое месиво она пока не превратилась (и, уж тем более, в месиво "полу NoSQLного кода").

Скажите, сколько человек поддерживают эту базу данных и насколько активно
она развивается. Это ответит на многие вопросы.
...
Рейтинг: 0 / 0
12.05.2016, 23:53
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234753
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

Помоему до тебя не доходит.

авторБерешь мою иерархию , запихиваешь ее в ОРМ (можешь и сам таблицы педалить, но мне кажется это жестоко даже для тебя). Потом берешь вытягиваешь ровно все эти данные с базы данных через АДО (или любую другу приблуду) на клиент и замеряешь трафик.

Я не намерен твой говнокод парсить. Необходима физическая модель и решаемая задача.

авторУгу, только Access писали в 90х, когда у всех на машинах трафик был даже не 128 кбит,

Сколько годиков было в 90ых? Тонкий Ethernet уже во всю рулил. А ты тут про какие-то 128 кбит поешь.

авторА MS SQL серьезная промышленная база данных, со всеми вытекающими оверхедами.

С какими?
...
Рейтинг: 0 / 0
12.05.2016, 23:55
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234754
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
stopmiksoftпропущено...
Забавно, этот топик собрал уже много излишне категоричных фраз.

У нас в корпоративной БД количество таблиц уже давно измеряется тысячами. Однако ни в какое месиво она пока не превратилась (и, уж тем более, в месиво "полу NoSQLного кода").
Скажите, сколько человек поддерживают эту базу данных и насколько активно
она развивается. Это ответит на многие вопросы.Примерно 2,5 человека. Развивается непрерывно. Правда, не понял, на какие вопросы это ответит.
...
Рейтинг: 0 / 0
12.05.2016, 23:57
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234755
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,
Я не намерен твой говнокод парсить. Необходима физическая модель и решаемая задача.


Классы (названия таблиц) есть.
Мемберы (название колонок) есть.
Типы колонок можно определить по выводу типов с правой стороны.

Твой запал "в бой" а потом резкий слив лишь говорит о том,
что ты примерно представляешь чем все закончится.

Ну ты не переживай, я тоже знаю что оверхед трафика для MS SQL превысит в разы.
...
Рейтинг: 0 / 0
12.05.2016, 23:58
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234756
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
stopМожет быть както так
Код: c#
1.
2.
3.
4.
5.
[
   {type:car, doc:{model:zaz,engine:1.2}},
   {type:employee, doc:{fname:ivan,lname:ivanov}},
   {type:author, doc:{author:shevchenko}},
]




А в таблицах это как будет ?
может быть как-то так


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
insert tbl
select '1\type\', 'car'
union select '1\doc\model','zaz'
union select '1\doc\engine','1.2'
union select '2\type\','emploer'
union select '2\doc\fname','ivan'
union select '2\doc\lname','ivanov'
union select '2\type\','author'
union select '2\doc\author','shevchenko'
...
Рейтинг: 0 / 0
13.05.2016, 00:02
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234757
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stopНу ты не переживай, я тоже знаю что оверхед трафика для MS SQL превысит в разы.

Опять один словесный понос. Меряться когда будем?
...
Рейтинг: 0 / 0
13.05.2016, 00:03
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234758
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stopТвой запал "в бой" а потом резкий слив лишь говорит о том,
что ты примерно представляешь чем все закончится

С больной головы на зоровую вот только не надо. :)
...
Рейтинг: 0 / 0
13.05.2016, 00:03
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234760
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinОпять один словесный понос. Меряться когда будем?

Да ты я как погляжу не уймешся.
Облегчим снова тебе многократно задачу.
Может уже твоей квалификации хватит сделать просто копи-паст...

Конечно тут трафик не меряли побайтно. Хотя задача трафико нагружаемая на 100%.
И разница с твоей любимой базой данной в 40 раз ...

Как ты думаешь, почему ?
(Сразу говорю, всем желающим предлагаю оптимизировать MS SQL код на свое усмотрение)
...
Рейтинг: 0 / 0
13.05.2016, 00:09
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234761
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Модератор: Коллеги прошу спокойствия. А то буду топик прикрывать
...
Рейтинг: 0 / 0
13.05.2016, 00:19
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234763
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

А там камменты можно оставлять? Что-то не вижи ни одного. Пиар ресурса здесь не приветствуется. По сути и не вникая особо в подробности - есть проблемы с проектированием, ибо пришлось такой лапшекод на транзакте нарисовать.

Ты не там ищешь серебряную пулю.
...
Рейтинг: 0 / 0
13.05.2016, 00:22
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234764
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
maytonМодератор: Коллеги прошу спокойствия. А то буду топик прикрывать

Дело не в топике, а в одном его участнике. Его и надо "прикрывать". Практического толку от него голимый ноль. Один самопиар.
...
Рейтинг: 0 / 0
13.05.2016, 00:23
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234765
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
pkarklinmaytonМодератор: Коллеги прошу спокойствия. А то буду топик прикрывать

Дело не в топике, а в одном его участнике. Его и надо "прикрывать". Практического толку от него голимый ноль. Один самопиар.да прикрыть то много ума не надо...
не нравится - ну не надо читать и вешать ярлыки типа "говнокода"
у меня вот сейчас на нечто подобное собираются переходить, я хочу например хоть какую-то пользу увидеть
...
Рейтинг: 0 / 0
13.05.2016, 00:27
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234767
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
SergSuper я хочу например хоть какую-то пользу увидеть

Дык я с этого и начал! Предложил провести тестирование. Площадку готов предоставить. Но получаю в ответ кучу лапшекода. Доколе?
...
Рейтинг: 0 / 0
13.05.2016, 00:29
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234768
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
2 pkarklin
Ну вот, мой бан спасет твою репутацию. Это верно.
Ссылку я не хотел приводить, просто ты ее выпросил.

PS:
А ты наверное думал что ядро и бородатые протоколы передачи MS SQL дают
+50 фрагов к скорости переключения p-n-p переходов на транзисторах в процессоре
и еще плюс 100 фрагов к скорости света при передачи по сети.
А оно вот оно как Михалыч. Несколько десятков тысяч комменариев иерархией noSql база данных
через АДО выгружает в 40к раз (ну ладно в 10 раз учитывая непревзойденный профессионализм, упорство и супер-пупер-мега оптимизации от мастер-гуру (я надеюс)) быстрее.

А ну прости. Я вспомнил что ты там чтото говорил про плюсики в дереве и особый код который обеспечит порционную загрузку через ajax дабы не прогинать могучий сервер.
...
Рейтинг: 0 / 0
13.05.2016, 00:29
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234769
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
SergSuper,

Ну, ты видел последний (я надеюсь) пост...
...
Рейтинг: 0 / 0
13.05.2016, 00:31
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234771
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinSergSuper,

Ну, ты видел последний (я надеюсь) пост...

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

В чем смысл тогда твоих дифирамбов. Я например с MS SQL
11+ лет знаком с тех пор как мне всучили его сертификаты.
Но у меня есть альтернативная точка зрения на его эффективность в определенных
ограниченных условиях. А у тебя к сожалению ограниченный и однобокий взгляд на
развитие систем управления базами данных. Увы. Как говорится, ниначем не настаиваю.
...
Рейтинг: 0 / 0
13.05.2016, 00:36
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234773
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

авторЗачем ты начинал этот пост если не хотел отстоять свою точку зрения ?
Я вроде тебе целенаправленный бенчмарк на счет трафика между прочим по сабжу прислал,
за который готов ответить за каждую цифру
и ты опять в кусты.
Мне казалось, я раз несколько повторил вопрос про решаемую задачу, а не про то, как ты ее решил.
авторВ чем смысл тогда твоих дифирамбов. Я например с MS SQL
11+ лет знаком с тех пор как мне всучили его сертификаты.
Везет, же. У меня вот нет сертификатов. С MS SQL знаком (да не может быть) уже лет 20ть...
авторНо у меня есть альтернативная точка зрения на его эффективность в определенных
ограниченных условиях
Жаль, что она не применима на практике. Тынцы на работающие решения, а не собственный ресур приветствуются!
авторА у тебя к сожалению ограниченный и однобокий взгляд на
развитие систем управления базами данных.
Это да. Он, так сказать, классическйий. Вся "новизна", как правило, на практике оказывается шелухой. Но у некоторых еще есть возможность это опровергнуть. Приведя, опять же, тынцы на промышленные работающие решения.
...
Рейтинг: 0 / 0
13.05.2016, 00:47
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234775
20 шт
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
20 шт
Участник
pkarklin,

вполне очевидно, что ты снова не вписываешься в формат обсуждения. Может, дашь людям завершить его?
...
Рейтинг: 0 / 0
13.05.2016, 00:50
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234776
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
20 штМожет, дашь людям завершить его?

Давай я это буду решать сам?!
...
Рейтинг: 0 / 0
13.05.2016, 00:52
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234777
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,
Мне казалось, я раз несколько повторил вопрос про решаемую задачу, а не про то, как ты ее решил.


По моей ссылке вроде есть.
авторКод моделирует ленту сообщений новостного сайта.
Комментарии в древовидной структуре.


Дальше по коду все вроде понятно.
К каждой странице 1000 комментариев иерархией. (10*10*10)

Дальше вроде как должен разбираться с MS SQL

pkarklinПриведя, опять же, тынцы на промышленные работающие решения.

Google, Facebook, Twitter у которых noSql базы данных на полную катушку
используются, подходят ? Или считается промышленным только Склад-Бухгалтерия, с 10 бухами на борту одновременно.
...
Рейтинг: 0 / 0
13.05.2016, 00:53
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234780
20 шт
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
20 шт
Участник
pkarklin20 штМожет, дашь людям завершить его?

Давай я это буду решать сам?!
Ну реши, пожалуйста, и смойся.
...
Рейтинг: 0 / 0
13.05.2016, 00:56
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234781
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stopGoogle, Facebook, Twitter у которых noSql базы данных на полную катушку

Господи... Если Google чего-нить не покажет в поисковой выдаче, то это никто не заметит, если в лицокниге или твитере пропадет пост, то никто не будет обрывать телефон службы поддержки банка, что у меня списали деньги, но операция не прошла.

Когда ты начнешь разделять системы, реализующие "бантики" и системы, где тебя за копейку тебя удушат, возможно ты повзрослеешь.
...
Рейтинг: 0 / 0
13.05.2016, 00:57
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234783
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstopGoogle, Facebook, Twitter у которых noSql базы данных на полную катушку

Господи... Если Google чего-нить не покажет в поисковой выдаче, то это никто не заметит, если в лицокниге или твитере пропадет пост, то никто не будет обрывать телефон службы поддержки банка, что у меня списали деньги, но операция не прошла.

Когда ты начнешь разделять системы, реализующие "бантики" и системы, где тебя за копейку тебя удушат, возможно ты повзрослеешь.

Днипра поддерживает три вида транзакций (ReadCommited, RepeatableRead, Snapshot),
поддерживает все четыре буквы ACID и поддерживает транзакционный лог, по которому можно, например, откатить даже закомиченные транзакции на определенную дату.

Реляционная модель данных, не имеет никакого прямого отношения к надежности хранения данных с технической точки зрения.
Просто так исторически сложилось, что почти все реляционки держат этот стандарт ACID. Но тормознутые они не потому что они надежные, а потому что они во-первых древние, код у них с душком как и влюбом бородатом проекте,
во-вторых модель данных оставляет желать лучшего (компактность иерархических представлений обсуждали, а ведь это только верхушка айсберга).
...
Рейтинг: 0 / 0
13.05.2016, 01:04
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234784
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
asphixНесколько удалённых офисов, ширина канала до сервера баз данных - (sic!) 128 кбит/с.
Пользователей сколько? Два или две тысячи?

P.S. Ох как страшно. У меня в своё время были каналы 9600 бит/с.

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

- СУБД надо выбрать так, чтобы хватало серверных возможностей (ну или приписывать свой AS)
- пары СУБД/способ доступа в принципе не помешает протестировать на процент хлама в сетевом протоколе, но по сравнению с влиянием архитектуры разница вряд ли окажется принципиальной.
...
Рейтинг: 0 / 0
13.05.2016, 01:13
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234785
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

авторДнипра поддерживает три вида транзакций (ReadCommited, RepeatableRead, Snapshot),
Когда будет Serializable - приходи. Oracle с собой не забудь захватить...
авторРеляционная модель данных, не имеет никакого прямого отношения к надежности хранения данных с технической точки зрения.
Просто так исторически сложилось, что почти все реляционки держат этот стандарт ACID.
Действительно не имеет. Странно, что ты вообще об этом упомянул. Держут их, далеко не все.
авторНо тормознутые они не потому что они надежные, а потому что они во-первых древние, код у них с душком как и влюбом бородатом проекте,
во-вторых модель данных оставляет желать лучшего ( компактность иерархических представлений обсуждали, а ведь это только верхушка айсберга ).
Видишь ли, в чем дело. Тебе опять придеться напомнить, что ты решаешь задачи вида сферического коня в вакууме в однопользовательском режиме, т.е. не имеющие практического смысла. Ты потрудись, найди в этом разделе приводимые мной показатели нагрузки реальных систем. Когда ты на примерно такой уровень выйдешь хоть на 5ть минут - приходи.
...
Рейтинг: 0 / 0
13.05.2016, 01:13
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234788
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,
авторДнипра поддерживает три вида транзакций (ReadCommited, RepeatableRead, Snapshot),
Когда будет Serializable - приходи. Oracle с собой не забудь захватить...


Внезапно, но Snapshot это и есть Serializable.

pkarklinstop,
Видишь ли, в чем дело. Тебе опять придеться напомнить, что ты решаешь задачи вида сферического коня в вакууме в однопользовательском режиме, т.е. не имеющие практического смысла. Ты потрудись, найди в этом разделе приводимые мной показатели нагрузки реальных систем. Когда ты на примерно такой уровень выйдешь хоть на 5ть минут - приходи.

Так это я тебе и пытаюсь донести. Никаких реальных нагруженных приложений на реляционке не получится.
Их удел - слабонагруженные системы с развесистыми отчетными подсистемами. Все что в сторону, уже начинаются кеширующие сервера и прочьи пляски с бубном.
...
Рейтинг: 0 / 0
13.05.2016, 01:19
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234789
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
stop,

авторВнезапно, но Snapshot это и есть Serializable.
Не говори это никому, ладно?
авторТак это я тебе и пытаюсь донести. Никаких реальных нагруженных приложений на реляционке не получится.
Ну как же ты можешь это до меня довести, если ты рядом не столят ни с одной нагруженной транзакционной системой. Гугл, твитер и и же с ним к ним не относятся.
авторИх удел - слабонагруженные системы с развесистыми отчетными подсистемами. Все что в сторону, уже начинаются кеширующие сервера и прочьи пляски с бубном.
Я не хочу снова повторять слова, которые вызывают оправданный гнев модераторов, но ты опять пишешь много слов, не имеющих смысловой нагрузки. Т.е. ты говоришь о том, о чем у тебя просто нет представления.
...
Рейтинг: 0 / 0
13.05.2016, 01:28
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234791
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
stopНикаких реальных нагруженных приложений на реляционке не получится.я так понимаю процессинг пластиковых карт - это слабонагруженная система, действительно виза, мастеркард всякий, несерьезно
а что такое тогда реально нагруженные? можно конечно назвать Google, Facebook, Twitter, но такие системы единичны, масштаб фирм такой что можно и специализированные базы себе написать, т.е. совсем не показатель
что остается тогда?
...
Рейтинг: 0 / 0
13.05.2016, 01:33
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234792
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
SergSuperstopНикаких реальных нагруженных приложений на реляционке не получится.я так понимаю процессинг пластиковых карт - это слабонагруженная система, действительно виза, мастеркард всякий, несерьезно
а что такое тогда реально нагруженные? можно конечно назвать Google, Facebook, Twitter, но такие системы единичны, масштаб фирм такой что можно и специализированные базы себе написать, т.е. совсем не показатель
что остается тогда?

Ну разные базы бывают.
Например скаченый размер этого форума, в районе 56 гигабайт.
При средней длине слова в русском языке 8 символов, можно посчитать что чтобы проиндексировать только этот сайт,
нужно выполнить около 7 миллиардов запросов за три-четыре часа, чтобы построить индекс.

И это не Google и не Facebook и сервер посредственный, ноутбук.

А Виза и Мастеркард - ооочень дорогое железо, которого много, плюс денормализированые данные, плюс куча специальных костыльных фишек типа блокировки сумм на картах, плюс двухфазные коммиты (а не всегда честные транзакции), плюс процессинг сумм карт в одной системе, ведение данных карт уже в другой. Короче всеравно процессить в реалтайм не такто всё и просто да и нагрузки там я бы не сказал что астрономические.
...
Рейтинг: 0 / 0
13.05.2016, 01:49
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234795
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
pkarklinstop,

авторВнезапно, но Snapshot это и есть Serializable.
Не говори это никому, ладно?

Я понял о чем ты говоришь.
Мой Snapshot в Днипре равен Serializable в MS SQL.
По сути он блокирует коммиты на время чтения, чем делает снапшот базы данных,
плюс делает блокировки тех данных, которые прочитал, во избежания перезаписи их другими транзакциями после завершения текущей.
...
Рейтинг: 0 / 0
13.05.2016, 01:59
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234956
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
stopSergSuperпропущено...
я так понимаю процессинг пластиковых карт - это слабонагруженная система, действительно виза, мастеркард всякий, несерьезно
а что такое тогда реально нагруженные? можно конечно назвать Google, Facebook, Twitter, но такие системы единичны, масштаб фирм такой что можно и специализированные базы себе написать, т.е. совсем не показатель
что остается тогда?

Ну разные базы бывают.
Например скаченый размер этого форума, в районе 56 гигабайт.
При средней длине слова в русском языке 8 символов, можно посчитать что чтобы проиндексировать только этот сайт,
нужно выполнить около 7 миллиардов запросов за три-четыре часа, чтобы построить индекс.

И это не Google и не Facebook и сервер посредственный, ноутбук.

А Виза и Мастеркард - ооочень дорогое железо, которого много, плюс денормализированые данные, плюс куча специальных костыльных фишек типа блокировки сумм на картах, плюс двухфазные коммиты (а не всегда честные транзакции), плюс процессинг сумм карт в одной системе, ведение данных карт уже в другой. Короче всеравно процессить в реалтайм не такто всё и просто да и нагрузки там я бы не сказал что астрономические.
sql.ru реально работает, тормознутости не наблюдаю
тоже самое касается и процессинга, что в самой визе, что в процесингах банков, не думаю что например Уралсиб покупал ооочень дорогое железо, а процессинги делали себе банки и поменьше

ну хорошо, нагрузки там неастрономические, а где тогда они серьезные?
...
Рейтинг: 0 / 0
13.05.2016, 10:59
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234971
Зимаргл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зимаргл
Гость
Пробегала статья сравнения трафика постгрес с ораклом. Что разница в трафике вдвое.

Погуглил, похоже в mssql компрессии TDS нет. Хм.
...
Рейтинг: 0 / 0
13.05.2016, 11:17
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39234992
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
ЗимарглПробегала статья сравнения трафика постгрес с ораклом. Что разница в трафике вдвое.

Погуглил, похоже в mssql компрессии TDS нет. Хм.
Трафик нужно сравнивать cколько на одну ODBC / JDBC инструкцию будет round-trip'ов. Собственно "байты" достаточно пофиг.

Тот же Oracle, до версии 11 не умел делать array fetch / bulk fetch с полями типа Blob. Т.ч. стоило бы в запросе появится Blob'полю или любому производному от него (например гео-данные) - тормоза по сети были бы обеспечены.

Т.ч. IMHO для задачи топикстартера, если канал реально никак не расширить - то одно из:
1) решения на базе аппликейшен сервера
В крайнем случае, можно посмотреть есть ли поддержка RPC /remote procedure call/ в Delphi и сделать свой "сервер". Разделить проект на две части - серверная, клиентская. И общаться через какой-то механизм взаимодействия
2) терминальные решения
3) что-то "смешанное". Например Oracle Forms при работе в режиме Web-Forms работает фактически как терминальный сервер. Отсылает туда-обратно нажатия клавиш и информацию которую нужно обновить на экране.

IMHO На каналах с большой задержкой - все протоколы работающие с БД скорее всего пойдут лесом. А, подозреваю, а автора задержки на канале будут из разряда "тушите свет".
...
Рейтинг: 0 / 0
13.05.2016, 11:31
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235017
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Тема жадных Блобов заинтересовала. Еще лет 10 назад у меня была мысль мелкие
блобы складывать в VARCHAR2(4000 bytes) в кодировке BASE64 той-же data-row при условии что размер
подходит (не больше кодированной строки).

Разумеется моя оптимизация базировалсь на предположении что 80-90% блобов будут мелкие.

Но сектор разработки тогда не поддержал мою идею. Хотя проблемы на канале были (ASDL модем между филиалами).
...
Рейтинг: 0 / 0
13.05.2016, 11:52
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235043
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
В начале 2000-х занимался оптимизацией для Oracle Forms.

Очень радовало, полное не совпадение данных по моем тестам и то, что было указано в нотах/инструкциях Oracle для Oracle Forms разработчиков. Например, их тесты которые якобы считали round trip'ы, считали совершенно другое. И с round-trip'ами на канале не совпадали, чуть более, чем полностью. Т.е. те советы которые давали ноты/примеры для Oracle Forms по оптимизации - делали хуже, чем стандартное поведение.

maytonТема жадных Блобов заинтересовала. Еще лет 10 назад у меня была мысль мелкие
блобы складывать в VARCHAR2(4000 bytes) в кодировке BASE64 той-же data-row при условии что размер
подходит (не больше кодированной строки).
А нафига? У Oracle есть RAW, правда не уверен, может ли он быть переменного размера. Скорее всего может.
maytonРазумеется моя оптимизация базировалсь на предположении что 80-90% блобов будут мелкие.

Но сектор разработки тогда не поддержал мою идею. Хотя проблемы на канале были (ASDL модем между филиалами).
У нас не так много было BLOB'ов.

Но зато часто было обращение к настроечным справочникам, которые не меняются

Т.ч. сделал механизм кэширования справочников на клиенте (просто свою реализацию вместо/поверх CREATE_RECORD_GROUP_WITH_QUERY) - на канале 32 Kbit ADSL все залетало.

Но на радио-канале с задержками до 0.5 - 1 sec. - тушите свет. Читал доки от оборудования (провайдер прислал доки на их базовые станции) откуда берутся такой разброс в задержках, даже не понял. Но так как провайдер, понятное дело, ради нас настраивать QoS (quality of service) отказался, то делать было нечего. Поставили Windows терминальный сервер - он не так с задержкам критичен, хотя ряд модулей пришлось доделывать (например работу с изображениями, т.к. он терминал тогда только 256 цветов давал).
...
Рейтинг: 0 / 0
13.05.2016, 12:24
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235056
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
На docs.oracle.com висит предупреждающая тряпочка.

The LONG RAW datatype is provided for backward
compatibility with existing applications. For new applications,
use the BLOB and BFILE datatypes for large amounts of binary data.

Oracle also recommends that you convert existing LONG RAW
columns to LOB columns. LOB columns are subject to far fewer
restrictions than LONG columns. Further, LOB functionality is
enhanced in every release, whereas LONG RAW functionality
has been static for several releases.
Я не очень верю что они задепрекейтят LONG* типы. Но имеет смысл
учитывать что LOB будут улучшать в части оптимизации хранения
и сжатия места.
...
Рейтинг: 0 / 0
13.05.2016, 12:40
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235105
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Я не про Long raw, а про просто Raw. Т.е. извращение с base64 и Varchar2 не нужно.
...
Рейтинг: 0 / 0
13.05.2016, 13:22
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235111
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Leonid Kudryavtsev,

авторВ крайнем случае, можно посмотреть есть ли поддержка RPC /remote procedure call/ в Delphi и сделать свой "сервер". Разделить проект на две части - серверная, клиентская. И общаться через какой-то механизм взаимодействия

Вызов хранимых процедур на стороне MS SQL через любой клиентский механизм доступа к данным это и есть RPC. Так что не надо никаких дополнительных серверов.
...
Рейтинг: 0 / 0
13.05.2016, 13:27
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235147
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Leonid KudryavtsevЯ не про Long raw, а про просто Raw. Т.е. извращение с base64 и Varchar2 не нужно.
Я как-то портировал одну СМС-ку с MS-SQL на оракл. И возникла задача перетащить SYS_GUIDS.
До меня кодеры успели наколотить OVER 9000 табличек где в оракле они заменяли MS-овскеий
SYS_GUID на оракловый RAW. Начали мигрировать клиента. Полная лажа. С кастингами замучались в PLSQL.
Тогда я плюнул. И заменил RAW на VARCHAR2 ... не помню какой длины ну вобщем это сериализованное
128 битное целое в строку + 3 или 4 дефиса в середине. Сразу стало легче. Об экономии особо не думали.
Главная задача была проект запустить. Но и щас я думаю что если эта ЦМС-ка жива - то там так и остался
VARCHAR2
...
Рейтинг: 0 / 0
13.05.2016, 13:55
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235171
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Участник
maytonзаменяли MS-овскеий SYS_GUID на оракловый RAWтак они ж оба физически 16 байт, только в ms sql отображается с -

maytonС кастингами замучались в PLSQL.в чем проблема оказалась?
...
Рейтинг: 0 / 0
13.05.2016, 14:16
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235173
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Уже и точно не вспомню. Но кажется они участвовали в строковых операциях. И публиковались.
...
Рейтинг: 0 / 0
13.05.2016, 14:19
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235251
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
maytonLeonid KudryavtsevЯ не про Long raw, а про просто Raw. Т.е. извращение с base64 и Varchar2 не нужно.
Я как-то портировал одну СМС-ку с MS-SQL на оракл. И возникла задача перетащить SYS_GUIDS.
До меня кодеры успели наколотить OVER 9000 табличек где в оракле они заменяли MS-овскеий
SYS_GUID на оракловый RAW. Начали мигрировать клиента. Полная лажа. С кастингами замучались в PLSQL.
Тогда я плюнул. И заменил RAW на VARCHAR2 ... не помню какой длины ну вобщем это сериализованное
128 битное целое в строку + 3 или 4 дефиса в середине. Сразу стало легче. Об экономии особо не думали.
Главная задача была проект запустить. Но и щас я думаю что если эта ЦМС-ка жива - то там так и остался
VARCHAR2
который раз убеждаюсь - вреда от guid больше чем пользы
...
Рейтинг: 0 / 0
13.05.2016, 15:27
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235318
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ivan Durakвреда от guid больше чем пользы
Если от дураков вообще нет никакой пользы кроме вреда, при чём тут GUID?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
13.05.2016, 16:17
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235342
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Сейчас ещё призрак Валеры налетит.
...
Рейтинг: 0 / 0
13.05.2016, 16:26
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235367
asphix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asphix
Гость
pkarklin, дельфа XE4
...
Рейтинг: 0 / 0
13.05.2016, 16:40
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235370
asphix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asphix
Гость
pkarklin, в это трудно поверить, но там самые настоящие старые модемы :)
...
Рейтинг: 0 / 0
13.05.2016, 16:41
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235377
asphix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asphix
Гость
softwarer, вот забано получается - сегодня много говорят о хайлоаде, а тут обратная задача =)))
...
Рейтинг: 0 / 0
13.05.2016, 16:44
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235391
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
asphixв это трудно поверить, но там самые настоящие старые модемы :)

А это невозможно поверить. У настоящих старых модемов предел скорости обмена 32 килобита.
64 для ISDN. 128 это уже DSL.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
13.05.2016, 16:48
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235401
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
А на каких скоростях работают банкоматы? Платежные терминалы?

Я не думаю что там мегабиты.

Ану банкиры колитесь.
...
Рейтинг: 0 / 0
13.05.2016, 16:51
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235412
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
Банкомат, это не толстый, а просто жирный клиент.
Его пакет данных это номер карты, какието пару ключей, банк эмитента, может быть чтото еще.
Все что делает банкомат, отправляет байт 100-200 в центр при транзакции, при этом еще умудряется на секунд 5-10 подвисать
и получает Ок или код ошибки и всё. Какое он имеет отношение к клиентам, которым грид может приехать от базы.

Ну я правда с банкоматами не работал, это просто инженерная мысль.
Банкомату хватит и 8кбит канал.
...
Рейтинг: 0 / 0
13.05.2016, 17:01
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235413
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Dimitry Sibiryakovasphixв это трудно поверить, но там самые настоящие старые модемы :)

А это невозможно поверить. У настоящих старых модемов предел скорости обмена 32 килобита.
64 для ISDN. 128 это уже DSL.Да почему невозможно-то?
До эпохи DSL были кабельные модемы, которые примерно такие скорости и выдавали. Вот , например.
А в промышленности, да на большие расстояния - вполне возможно и сейчас .
...
Рейтинг: 0 / 0
13.05.2016, 17:01
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235417
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
maytonА на каких скоростях работают банкоматы? Платежные терминалы?Им хватает обычного GPRS.
А кассовые терминалы для оплаты картами еще не так давно со встроенным диалап-модемом были.
...
Рейтинг: 0 / 0
13.05.2016, 17:04
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235418
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
stopНу я правда с банкоматами не работал, это просто инженерная мысль. Банкомату хватит и 8кбит канал.
У банкомата основной траффик - это реклама. В смысле та муть, которую он крутит в заставке.
...
Рейтинг: 0 / 0
13.05.2016, 17:04
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235422
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
softwarerstopНу я правда с банкоматами не работал, это просто инженерная мысль. Банкомату хватит и 8кбит канал.
У банкомата основной траффик - это реклама. В смысле та муть, которую он крутит в заставке.

На самом деле не реклама, а видео, которое пишут даже старые досовские банкоматы.
Но он это видео на локальный сторадж скорей всего сохраняет, потом удаляет по истечении времени.
...
Рейтинг: 0 / 0
13.05.2016, 17:06
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235433
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
stopНа самом деле не реклама, а видео, которое пишут даже старые досовские банкоматы. Но он это видео на локальный сторадж скорей всего сохраняет, потом удаляет по истечении времени.
Наверняка сохраняет. И так же наверняка качает с центра. Вот в жизни не поверю, что банковским программистам нравится разъезжать и обновлять эти ролики на 100500-х банкоматах.
...
Рейтинг: 0 / 0
13.05.2016, 17:15
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235439
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
В самом худшем раскладе я-бы предложил автору публиковать обновления справочников
в вебе или в NFS и раз в сутки синкать их через rsync или wget
...
Рейтинг: 0 / 0
13.05.2016, 17:17
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235442
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
stopБанкомат, это не толстый, а просто жирный клиент.
Его пакет данных это номер карты, какието пару ключей, банк эмитента, может быть чтото еще.
Все что делает банкомат, отправляет байт 100-200 в центр при транзакции, при этом еще умудряется на секунд 5-10 подвисать
и получает Ок или код ошибки и всё. Какое он имеет отношение к клиентам, которым грид может приехать от базы.

Ну я правда с банкоматами не работал, это просто инженерная мысль.
Банкомату хватит и 8кбит канал.
Не уверен. Если заказать выписку по движению средств то наверное траф будет чуть поболее.

Хотя в 99% случаев это операции типа пополнить баланс или чето снять.

P.S. Тоже инженерная мысль.
...
Рейтинг: 0 / 0
13.05.2016, 17:19
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235446
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
maytonВ самом худшем раскладе я-бы предложил автору публиковать обновления справочников
в вебе или в NFS и раз в сутки синкать их через rsync или wget
Зачем? Просто в запрос справочника вставить where scn > :scn и сливать с ранее полученным. Если начнут напрягать даже пустые запросы - добавить на клиенте перезапрос не чаще раза в N минут.
...
Рейтинг: 0 / 0
13.05.2016, 17:20
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235483
stop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stop
Участник
maytonstopБанкомат, это не толстый, а просто жирный клиент.
Его пакет данных это номер карты, какието пару ключей, банк эмитента, может быть чтото еще.
Все что делает банкомат, отправляет байт 100-200 в центр при транзакции, при этом еще умудряется на секунд 5-10 подвисать
и получает Ок или код ошибки и всё. Какое он имеет отношение к клиентам, которым грид может приехать от базы.

Ну я правда с банкоматами не работал, это просто инженерная мысль.
Банкомату хватит и 8кбит канал.
Не уверен. Если заказать выписку по движению средств то наверное траф будет чуть поболее.

Хотя в 99% случаев это операции типа пополнить баланс или чето снять.

P.S. Тоже инженерная мысль.

Такая функция в большинстве банкоматов вообще не доступна.
Выписка может содержать сотни транзакций за период и
это немного не формат для экранчиков банкоматов.
...
Рейтинг: 0 / 0
13.05.2016, 18:07
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235489
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Я как-то делал выписки. По альфа-банку. Кажется он их сливает не на скрин а на кассовую
ленту.
...
Рейтинг: 0 / 0
13.05.2016, 18:14
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235593
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
asphixдельфа XE4

Ууу... У нас еще работают приложения на 5ке и 7ке.
...
Рейтинг: 0 / 0
13.05.2016, 22:33
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39235596
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
asphixв это трудно поверить, но там самые настоящие старые модемы :)

Не настаиваю, но попробуйте MS SQL. Если грамотно организовать работу с данными, то даже при такой пропускной способности проблем особых быть не должно в озвученных ТТХ БД.
...
Рейтинг: 0 / 0
13.05.2016, 22:36
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39236289
Фотография S.G.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
S.G.
Участник
asphix Есть задача написать клиент-серверное CRUD-приложение (толстый клиент). Несколько удалённых офисов, ширина канала до сервера баз данных - (sic!) 128 кбит/с. Текущая поделка на Access 2007 безбожно тормозит. Посоветуйте что лучше использовать для реализации?

Изначально планируется клиент на Delphi. Вопрос в выборе СУБД (MySQL, PostgreSQL, etc..) и в выборе технологии коннекта (ADO, FireDAC, etc..)У меня как-то был похожий случай. Клиент на Дельфи, прекрасно работающий в локальной сети, и вдруг "а давай поставим рабочее место в пригороде, там людям иногда надо поработать удаленно".
Поставил. Форма с 3-4 справочниками и мастер-деталь таблицами открывалась минут 5. Так что, при большом желании и терпении, можно было работать .. но второй раз я бы это не пробовал :)

Так что тоже посоветую - веб или терминал.

Если с веб-ом у вас не очень, то под Дельфи есть неплохой фреймворк, в котором все пишется как на дельфи, но в конечном счете создается веб-страничка. Называется UniGUI. При этом уже сама БД и доступ к ней не имеют значения, во всяком случае в связке Firebird + FibPlus + Дельфи все получается без проблем.

здесь демо:
http://www.unigui.com/demo
...
Рейтинг: 0 / 0
16.05.2016, 10:04
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39236377
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
softwarermaytonВ самом худшем раскладе я-бы предложил автору публиковать обновления справочников
в вебе или в NFS и раз в сутки синкать их через rsync или wget
Зачем? Просто в запрос справочника вставить where scn > :scn и сливать с ранее полученным. Если начнут напрягать даже пустые запросы - добавить на клиенте перезапрос не чаще раза в N минут.
Я поднимаю обе руки вверх и говорю я не против. Но автор начинал с Акцесса а я невкурсе
понимает он :scn или нет.
...
Рейтинг: 0 / 0
16.05.2016, 11:38
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39236378
asphix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asphix
Гость
S.G., спасибо за наводку. Обязательно рассмотрю это решение!
...
Рейтинг: 0 / 0
16.05.2016, 11:40
| Ответить | Цитировать | Написать  
Выбор СУБД для медленного канала
    #39252549
scf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scf
Участник
В случае узкого канала и высоких пингов самое эффективное по траффику решение это один из двух вариантов:
- самопальный двоичный асинхронный RPC со сжатием. Например, на основе того же google protobuf.
- локальная БД на клиенте с синхронизацией.

Или что-то среднее между двумя этими подходами - что-то имеет смысл кешировать, что-то - запрашивать каждый раз с сервера, а для чего-то еще - вести версию данных и указывать её при запросе.
...
Рейтинг: 0 / 0
08.06.2016, 10:36
| Ответить | Цитировать | Написать  
159 сообщений из 159, показаны все 7 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор СУБД для медленного канала
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=35&tid=1552265]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 159ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 136ms
get tp. blocked users:
 2ms
others: 242ms
total:  584ms
созд. / загр.: 584ms
x
x
Закрыть


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