DB/2. ацтой или рай?

← →
Кщд (2013-07-30 17:04) [80]

>Jeer © (30.07.13 16:19) [69]
>Есть те, кто пишет удовлетворительно и этого достаточно для решения предложенных, а не выдуманных задач.
с этим никто не спорил

← →
Кщд (2013-07-30 17:07) [81]

>разработчик (30.07.13 17:00) [78]
>В таких случаях я обычно все стирал, немного думал и писал прозрачный, понятный легко сопровождаемый код.
пожалуйста, покажите Ваш код на PL/SQL, работающий с данными, а именно: выборки, изменения данных в таблицах, да хоть курсоры с записями)

← →
и как это будет выглядеть (2013-07-30 17:11) [82]

У нас больше 6 тыс. хранимых процедур в базе.
Как с помощью сабжа реализовать одновременную работу на MSSQL и Oracle, например? Легким движением руки переписать over 6 тыс. хранимок?

← →
Jeer © (2013-07-30 17:11) [83]

разработчик (30.07.13 16:03) [60]

>Что делать, когда данных возвращается очень много (ну хотя бы более десяти тысяч строк)?

>Грид. Фильтрация по колонке. Пользовательская.
>щас скажут что это отстой и нельзя десять тысяч строк в грид.

У меня сплошная "шахматка" на клиенте - RB-OLAP, знаете ли..

Бывает клиент вытягивает на 3..5 лет, 365 дней, 24 района или 200-500 показателей.
Ну надо ему так. Легко вылетаем под 100 тыщ

← →
Юрий Зотов © (2013-07-30 17:12) [84]

Насколько я понял, это что-то вроде плагинной архитектуры. Каждый плагин заточен под свою БД, а их интерфейс с ядром унифицирован.

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

Если это так, то почему бы и нет? Вполне реализуемо.

← →
разработчик (2013-07-30 17:14) [85]

for i in (select...) loop
null;
end loop;

Ах да! Как же это я так облажался.
Это же на каждой итерации имеем переключение контекста.
Все верно.
Надо юзать форол.

смысл вопроса-то в чем?
А как же это будет работать в фб?

Никак не будет.
Потому что в фб другой код.

← →
разработчик (2013-07-30 17:16) [86]

Насколько я понял, это что-то вроде плагинной архитектуры. Каждый плагин заточен под свою БД, а их интерфейс с ядром унифицирован.

Вот.
Почти в яблочко. Потому что сделано без классических плагинов.
Но суть верна. Унифицированный интерфейс к БД-специфичным модулям.

← →
разработчик (2013-07-30 17:18) [87]

Бывает клиент вытягивает на 3..5 лет, 365 дней, 24 района или 200-500 показателей.
Ну надо ему так. Легко вылетаем под 100 тыщ

И в чем проблема?
Вытягиваете сто тыщ? Вытягиваете.
Надо оно? Видимо надо.

А раз надо то вытяну и я.

← →
Jeer © (2013-07-30 17:22) [88]

>И в чем проблема?

Я не к Вам -я к тем, кто боится вытянуть на клиента больше 100 записей:)

← →
Inovet © (2013-07-30 17:24) [89]

> [88] Jeer © (30.07.13 17:22)
> кто боится вытянуть на клиента больше 100 записей:)

Про грид говорили

← →
Jeer © (2013-07-30 17:30) [90]

>Про грид говорили

Да, увы - у меня в гриде (не в DB) может быть свыше 100 тыщ

← →
Пит (2013-07-30 17:30) [91]

> Легко вылетаем под 100 тыщ

на клиентском гриде больше 100 тысяч записей? Мощно.

← →
Jeer © (2013-07-30 17:32) [92]

Да, шахматка и необходимость очень быстро крутить 2D в пространстве 5-12 измерений.
OLAP, однако.

← →
Пит (2013-07-30 17:32) [93]

> Да, увы - у меня в гриде (не в DB) может быть свыше 100
> тыщ

на мой взгляд это однозначно говорит о плохом проектировании проекта. Нереально пользователю работать со 100 тысячами записей. Вытягивать смысл имеет то, что пользователь может посмотреть визуально. Просмотреть 100 тыщ записей невозможно.

← →
Кщд (2013-07-30 17:32) [94]

>разработчик (30.07.13 17:14) [85]
можно реальный пример кода?
и на заметку: использование forall - это массовое связывание и не исключает возможность переключения контекста

for i in (select...) loop null; end loop;
Вам известно, к чему может привести подобная конструкция на часто меняющихся записях в таблицах из условия from?
Вам известны методы обхода проблемы?

← →
Пит (2013-07-30 17:33) [95]

> Да, шахматка и необходимость очень быстро крутить 2D в пространстве
> 5-12 измерений.
> OLAP, однако.

причем тут грид?

Ты грид с датасетом не перепутал? Хотя и для датасета это дофига.

← →
Jeer © (2013-07-30 17:34) [96]

Реально ( по статистике ) - 2-5 тысяч информативных единиц, но могут засандалить и 100 тыш.

← →
Пит (2013-07-30 17:36) [97]

> Вам известно, к чему может привести подобная конструкция
> на часто меняющихся записях в таблицах из условия from?

ты уже давал ответ в этой теме ))

Слушайте, а почему при for in будет переключение контекста на каждой итерации?

← →
Пит (2013-07-30 17:38) [98]

> Реально ( по статистике ) - 2-5 тысяч информативных единиц,
> но могут засандалить и 100 тыш.

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

← →
Jeer © (2013-07-30 17:38) [99]

>Просмотреть 100 тыщ записей невозможно.

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

Это "особая" технология спаривания реляционного движка на серваке и OLAP-движка на клиенте.

← →
Jeer © (2013-07-30 17:41) [100]

Юзер может отдать эти 100 тыщ или меньше для скармливания SPSS или в Статистику, но для этого ему надо глобально окинуть взглядом поле.
В общем, не судите того и то, в чем вам не айс.

← →
Пит (2013-07-30 17:41) [101]

> Юзер берет на себя то, что посчитал нужным и далее, методом
> "половинного деления"

а так если известен принцип "деления", почему сразу не предоставить искомые данные после n"ой итерации деления?

← →
Jeer © (2013-07-30 17:44) [102]

Принцип не известен - это аналитическая работа аналитика же, в стиле Data Mining.

← →
Jeer © (2013-07-30 17:45) [103]

Аналитику в помощь не только грид, но и графики, диаграммы и он творит по ходу дела свое видение результирующего отчета с данными: отбраковка, интер-, экстраполяция, прогноз..

← →
разработчик (2013-07-30 17:47) [104]

Ну и в заключении этой длинной ветки напишу зачем это было сделано.

Исходная задача - многопользовательское клиент-серверное ПО.
Выбрана связка ФБ + АДО + оле-дб провайдер для ИБ.
Почему адо? Потому что оно все равно нужно было для операций импорта.
Решил сэкономить на юзез.

Написал, отладил, сделал первые инсталляции.

Спустя неделю на блобах, на ровном месте получаю баг "ошибка во время многошаговой операции, обратитесь в лигу сексуальных реформ"

Обратился. Разрабы провайдера пояснили что в провайдере предназначенном для делфийской версии адо это не лечится.

Времени копать нет, принято решение перейти на прямой доступ через фиб.

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

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

Получилось.

Затем внезапно оказалось, что оказывается сделать форк под другие сервера - проще простого. Так появились версии под пять серверов, к которым у меня были адекватные библиотеки доступа. Сначала чисто из спортивного интереса.

Затем в процессе внедрений появились клиенты которые говорят:

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

И действительно зачем?
С тех пор, когда появляется новый клиент, ему задается пара вопросов:
- мультиплеер нужен?
- нет, у меня все на моем ноуте.
- окей, вот вам версия на файлах акцесса.

- Нужен мультиплеер?
- Нужен!
- Промышленные сервера какие-нибудь уже есть?
- Есть MSSQL.
- Нате вам многопользвательскую версию на MSSQL

А если сервер меняется, то с версии для MSSQL легко перепрыгиваем на любую другую через экспорт в mdb и импорт в новый целевой сервер.
А мдб этот одновременно является рабочим вариантом для однопользовательской версии адо/акцесс

И все счастливы.

← →
Пит (2013-07-30 17:48) [105]

все таки мне кажется ты перепутал грид с датасетом.

Я могу понять потребность грузить 100 тысяч записей, чтобы быстро с ними работать в оперативной памяти.

Но выводить в грид 100 тысяч строк? Да одна полоса прокрутки станет нереально узкой и непозиционируемой. Что там можно проанилизировать среди такого числа данных? слабо верится.

← →
Jeer © (2013-07-30 17:49) [106]

Ну и молодец - хорошее решение.

← →
Jeer © (2013-07-30 17:53) [107]

>все таки мне кажется ты перепутал грид с датасетом.

Все, что юзер вытянул реляционно, становится локальным датасетом и с ним работает OLAP-движок, визуализируя в грид в который можно выложить весь локальный датасет или нет - это аналитику решать.

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

← →
Пит (2013-07-30 18:05) [108]

люди, расскажите почему в for in каждую итерацию переключается контекст?

← →
разработчик (2013-07-30 18:14) [109]

потому что сам цикл это sql
а внутри него обычно код на плскл

и на каждой итерации сервер надрывается, переключаясь с контекста sql на контекст pl/sql

> [90] Jeer © (30.07.13 17:30)
> Да, увы - у меня в гриде (не в DB) может быть свыше 100 тыщ

Именно в гриде отображаются 100 тыщ? Не для обработки, не в кубе каком?

> [92] Jeer © (30.07.13 17:32)
> Да, шахматка и необходимость очень быстро крутить 2D в пространстве
> 5-12 измерений.
> OLAP, однако.

Ну так не грид же.

← →
Пит (2013-07-30 19:02) [112]

> и на каждой итерации сервер надрывается, переключаясь с
> контекста sql на контекст pl/sql

обманываете вы меня: http://www.oracle.com/technetwork/issue-archive/2012/12-sep/o52plsql-1709862.html

))

← →
разработчик (2013-07-30 20:33) [113]

ну так вы сначала определитесь, про что вы спрашивали.
про for i in (select)

или про форолл и булк.

Inovet © (30.07.13 18:40) [111]
>Ну так не грид же.

Локальный Dataset из которого выплескивается в грид по выбору аналитика возможно все.

Т.е. технология такова:
- аналитиком делается предварительный выбор данных из реляционной СУБД и они уходят в локальный DS.
Аналитик их крутит как хочет, выбирая 2D из многомерного пространства, создает вычислимые сущности, анализирует графики, диаграммы - если нужно, делает подзапрос из БД.

Что может быть в начале? Да, 100500 записей.
Что остается в конце - аналитику решать.

← →
Кщд (2013-07-30 21:56) [115]

>Пит (30.07.13 17:36) [97]
>Слушайте, а почему при for in будет переключение контекста на каждой итерации?
"не читайте советских газет" (с)
forall не альтернатива for t in (select...) loop null; end loop;
это альтернатива for t in (select...) loop DML_operation; end loop;
т.е. forall осуществляет массовое связывание(bulk binding), и потому context switching происходит всего лишь два раза: PL/SQL -> SQL -> PL/SQL

>ты уже давал ответ в этой теме ))
конечно
но мне интересен код, с помощью которого "разработчик" избегает/обрабатывает таких(ие) ситуаций(ии).

← →
Кщд (2013-07-30 22:01) [116]

>разработчик (30.07.13 18:14) [109]
"цикл в sql" - браво, отсыпите?

>Jeer © (30.07.13 20:46) [114]
>Локальный Dataset из которого выплескивается в грид по выбору аналитика возможно все. Т.е. технология такова...
Вы свой BI написали?

Практически - да.

P.S.
Причем отвязанный от технологий надстроек или встроек MS, Oracle над/в их "могучие" СУБД.

← →
Кщд (2013-07-30 22:10) [119]

>Jeer © (30.07.13 22:02) [117]
интерес праздный: чем не устроили решения от корифеев - Oracle, MS, да - чёрт возьми - Pentaho?

← →
Кщд (2013-07-30 22:14) [120]

>Jeer © (30.07.13 22:07) [118]
так, все BI от этих производителей умеют работать с данными из разнородных источников
либо поясните, пожалуйста, что имеете в виду?

DB/2. ацтой или рай? Найти похожие ветки