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

Откуда:
Сообщений: 3
Всем привет!!!

Прошу помочь в выборе СУБД для реализации следующей задачи
1) Справочники: на входе в программу поступает изначально неизвестное количество справочников с неизвестным количеством реквизитов в виде XML файла. Единственный реквизит который будет у всех - это id. Структура XML как-раз и определяет структуру наших будущих справочников (Название справочника, Название реквизитов, и соответственно количество реквизитов)
Например <object class="nomenklatura">
<void property="guid"><string>90fb867c-1669-11e8-bf56-6c71d9a36bc0</string></void>
<void property="kod"><string>00-00000001</string></void>
<void property="naimenovanie"><string>шкаф-купе</string></void>
</object>
<object class="kontragenti">
<void property="guid"><string>0e016a1f-be1f-11e7-a20e-00155d33f636</string></void>
<void property="naimenovanie"><string>сковороднева анна викторовна</string></void>
<void property="inn"><string>778945656</string></void>
<void property="kpp"><string>566246778</string></void>
</object>

2) Аналитические данные: так же на входе в виде XML поступает набор <дата>, <сумма>, <id показателя>, <id элемента справочника 1>, <id элемента справочника 2>, <id элемента справочника 3>,... <id элемента справочника N>
где дата - время когда был произведена операция, сумма - численное значение (количество чего-то), id показателя - это элемент справочника показателей, <id элемента справочника а> - элемент какого-то справочника а (либо номенклатура, либо контрагент, либо еще какой-то). Показатель же в этом случае выступает в качестве идентификатора произведенной операции и набора справочников.
Пример справочника показателей:
id=1 , наименование=Выручка, Справочники=[kontragenti, nomenklaturi, podrazdelenie]
id=2 , наименование=Маржинальный доход , Справочники = [kontragenti, nomenklaturi , podrazdelenie , sklad ]
id=3 , наименование=Запасы готовой продукции , Справочники = [podrazdelenie, sklad, nomenklaturi]

В итоге в таблице аналитических данных должно сконцентрироваться описание произведенных операций в разрезе аналитических данных, количество которых у всех операций разное в зависимости от показателя.
Количество показателей может достигать 15 - 20, и соответственно учитывая количество номенклатур, контрагентов, складов, подразделений и т.д. количество строк аналитической информации может накапливаться 1 - 100 млн. в год.

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

Вопрос: какую СУБД посоветуете для реализации данной задачи и не менее важное условие - бесплатная СУБД.
1 мар 19, 11:31    [21822511]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
L_argo
Member

Откуда:
Сообщений: 889
MySQL или PostGre бери.
1 мар 19, 13:31    [21822676]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Dimitry Sibiryakov
Member

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

trual
какую СУБД посоветуете для реализации данной задачи

Ту, которую знает тот, кто будет эту задачу решать. Ибо СУБД как таковая тут сугубо
перпендикулярна и всё зависит от рук программиста.

Posted via ActualForum NNTP Server 1.5

1 мар 19, 13:49    [21822701]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
mad_nazgul
Member

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


Не структурированные данные плохо ложатся на РМД.
Тут вам либо EAV делать, тогда ни о какой скорости говорить нельзя.
Либо таки углубятся в предметную область и строить РМД.

Можно попробовать взять PostgreSQL и работать с JSON-ами, но опять же ни о какой скорости нельзя говорить.
1 мар 19, 14:46    [21822773]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
trual
Member

Откуда:
Сообщений: 3
mad_nazgul,
Как раз скорость очень важна. Но идея имеет место быть потому что по реквизитам не будет фильтрации. Фильтрация по id элементов справочников-аналитик и по id показателей.
1 мар 19, 15:48    [21822832]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
trual
Member

Откуда:
Сообщений: 3
С колоночными СУБД никто не сталкивался? ClickHouse например
1 мар 19, 15:50    [21822836]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Dimitry Sibiryakov
Member

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

mad_nazgul
Тут вам либо EAV делать, тогда ни о какой скорости говорить нельзя.

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

Posted via ActualForum NNTP Server 1.5

1 мар 19, 16:12    [21822859]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3618
trual
mad_nazgul,
Как раз скорость очень важна. Но идея имеет место быть потому что по реквизитам не будет фильтрации. Фильтрация по id элементов справочников-аналитик и по id показателей.

монго.... ничего не умеет кроме как быстро хранить такие вот доки... и только по id искать
5 мар 19, 09:00    [21825039]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2027
trual
mad_nazgul,
Как раз скорость очень важна. Но идея имеет место быть потому что по реквизитам не будет фильтрации. Фильтрация по id элементов справочников-аналитик и по id показателей.

MongoDB

умеет хранить неизвестное количество реквизитов и очень быстро доставть по id
также поддерживает различные индексы, представления, агрегацию, свой язык запросов, которые также быстрые, если используются индексы, а не полное сканирование
в 4-й версии появились транзакции
5 мар 19, 09:06    [21825041]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2027
Также из коробки Replica Set для надёжности и Sharding для масштабирования
5 мар 19, 09:08    [21825042]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Glebanski
Member

Откуда: Msk ->NL
Сообщений: 292
На хабре деятель все-таки скрестил ежа с ужом в MySQL
https://habr.com/ru/company/oleg-bunin/blog/443422/
До того, как появился MySQL 5.7, люди тоже хранили JSON, но как поле text. Поле JSON в MySQL позволяет хранить сам JSON наиболее эффективно. Кроме того, на основе JSON можно создать виртуальные колонки и на их основе индексы.


Его там поругивают, но не очень активно. Ибо прогеры в основном за JSON в любой бочке
13 мар 19, 12:20    [21831149]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
недавно у яндекса смотрел видео, как они собирают метрики,хранят их и выводят аналитику. Поищите -там ваш случай. Причем там как было и как стало. Возможно вам как было будет интереснее.
13 мар 19, 13:36    [21831284]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2027
Озверин,

искать-то как? По "Озверин недавно у яндекса смотрел видео"? :)
13 мар 19, 21:04    [21831827]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
miksoft
Member

Откуда:
Сообщений: 37672
Дмитрий Мух,

ClickHouse это
13 мар 19, 21:44    [21831861]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Дмитрий Мух
Озверин,

искать-то как? По "Озверин недавно у яндекса смотрел видео"? :)


https://google.gik-team.com/?q=яндекс доклад метрики высокая нагрузка
14 мар 19, 09:41    [21832066]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26604
Озверин
Дмитрий Мух
Озверин,

искать-то как? По "Озверин недавно у яндекса смотрел видео"? :)


https://google.gik-team.com/?q=яндекс доклад метрики высокая нагрузка

Не могли бы вы теперь дать прямую ссылку на видео, о котором писали выше?
14 мар 19, 10:11    [21832095]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
skyANA
Озверин
пропущено...


https://google.gik-team.com/?q=яндекс доклад метрики высокая нагрузка

Не могли бы вы теперь дать прямую ссылку на видео, о котором писали выше?


нет, конечно.
14 мар 19, 10:38    [21832144]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2108
trual
Всем привет!!!

Прошу помочь в выборе СУБД для реализации следующей задачи
1) Справочники:
...
2) Аналитические данные:
...
Пример справочника показателей:
id=1 , наименование=Выручка, Справочники=[kontragenti, nomenklaturi, podrazdelenie]
id=2 , наименование=Маржинальный доход , Справочники = [kontragenti, nomenklaturi , podrazdelenie , sklad ]
id=3 , наименование=Запасы готовой продукции , Справочники = [podrazdelenie, sklad, nomenklaturi]

В итоге в таблице аналитических данных должно сконцентрироваться описание произведенных операций в разрезе аналитических данных, количество которых у всех операций разное в зависимости от показателя.
Количество показателей может достигать 15 - 20, и соответственно учитывая количество номенклатур, контрагентов, складов, подразделений и т.д. количество строк аналитической информации может накапливаться 1 - 100 млн. в год.

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

Вопрос: какую СУБД посоветуете для реализации данной задачи и не менее важное условие - бесплатная СУБД.

Вообще описание задачи (а в особенности примеры))) очень похоже на OLAP.
Измерения, факты...
Вы, кстати, вероятно забыли упомянуть, что ваши справочники имеют иерархию, и надо будет строить отчеты по разным уровням иерархии. Та же номенклатура.

Посмотрите на Pentaho. Может, то что надо.
14 мар 19, 15:52    [21832756]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 680
s_ustinov
trual
Всем привет!!!

Прошу помочь в выборе СУБД для реализации следующей задачи
1) Справочники:
...
2) Аналитические данные:
...
Пример справочника показателей:
id=1 , наименование=Выручка, Справочники=[kontragenti, nomenklaturi, podrazdelenie]
id=2 , наименование=Маржинальный доход , Справочники = [kontragenti, nomenklaturi , podrazdelenie , sklad ]
id=3 , наименование=Запасы готовой продукции , Справочники = [podrazdelenie, sklad, nomenklaturi]

В итоге в таблице аналитических данных должно сконцентрироваться описание произведенных операций в разрезе аналитических данных, количество которых у всех операций разное в зависимости от показателя.
Количество показателей может достигать 15 - 20, и соответственно учитывая количество номенклатур, контрагентов, складов, подразделений и т.д. количество строк аналитической информации может накапливаться 1 - 100 млн. в год.

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

Вопрос: какую СУБД посоветуете для реализации данной задачи и не менее важное условие - бесплатная СУБД.

Вообще описание задачи (а в особенности примеры))) очень похоже на OLAP.
Измерения, факты...
Вы, кстати, вероятно забыли упомянуть, что ваши справочники имеют иерархию, и надо будет строить отчеты по разным уровням иерархии. Та же номенклатура.

Посмотрите на Pentaho. Может, то что надо.


Pentaho и иже с ними работает по готовым таблицам- а тут эти таблицы "сваливаются на голову" и нужно как то динамически под них таблицы создавать по структуру пришедшую в xml. Если поток данных большой- EAV не вариант, чего бы не говорили его апологеты.
Вообще вопрос имеет мало отношение к выбору СУБД,поскольку обработка приходящего потока данных будет за пределами СУБД. Ну а СУБД нужно использовать ту, которую хорошо знаете. 100 млн. в год. это ни о чем объем.
14 мар 19, 23:35    [21833119]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2108
Serguei
s_ustinov
пропущено...

Вообще описание задачи (а в особенности примеры))) очень похоже на OLAP.
Измерения, факты...
Вы, кстати, вероятно забыли упомянуть, что ваши справочники имеют иерархию, и надо будет строить отчеты по разным уровням иерархии. Та же номенклатура.

Посмотрите на Pentaho. Может, то что надо.


Pentaho и иже с ними работает по готовым таблицам- а тут эти таблицы "сваливаются на голову" и нужно как то динамически под них таблицы создавать по структуру пришедшую в xml. Если поток данных большой- EAV не вариант, чего бы не говорили его апологеты.
Вообще вопрос имеет мало отношение к выбору СУБД,поскольку обработка приходящего потока данных будет за пределами СУБД. Ну а СУБД нужно использовать ту, которую хорошо знаете. 100 млн. в год. это ни о чем объем.

Данные о продажах никогда не "самозарождаются" в виде xml файлов.

То, что ТС написал - это описание OLAP. И изобретать велосипед - не лучшее решение. Самый правильный вариант - перейти в соседний раздел форума и почитать там, что и как делать.

Впрочем, если надо решать задачу "копать от забора до обеда" - можно выбрать хоть "Стебелек".
15 мар 19, 00:19    [21833134]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 216
s_ustinov
Данные о продажах никогда не "самозарождаются" в виде xml файлов.

То, что ТС написал - это описание OLAP. И изобретать велосипед - не лучшее решение. Самый правильный вариант - перейти в соседний раздел форума и почитать там, что и как делать.

Впрочем, если надо решать задачу "копать от забора до обеда" - можно выбрать хоть "Стебелек".

олап уже какое-то время отмирает, у майкрософта часть что класический олап лет 5 уже не развивается.
имхо проблема у задачки не куда писать, объемы крошечные, а то что по большому счету хранилище строить надо бы. данные явно валидировать и чистить, не понятно что делать если факт пришел а справочника к нему не пришел. как выглядит исправленный факт, что с этим делать ? история то наверно тоже ?
я бы apache spark вычитывал xml и импортировал валидированные данные в файлики колончатой структуры типа parquet или orc. структуры типа снежинка или звезда вроде уже не модно, наверно клал бы в какой-нить вариант Slowly Changing Dimension (SCD). и уже обработанные данные писал бы в рсубд для отчетной системы.
15 мар 19, 08:49    [21833271]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2108
H5N1
s_ustinov
Данные о продажах никогда не "самозарождаются" в виде xml файлов.

То, что ТС написал - это описание OLAP. И изобретать велосипед - не лучшее решение. Самый правильный вариант - перейти в соседний раздел форума и почитать там, что и как делать.

Впрочем, если надо решать задачу "копать от забора до обеда" - можно выбрать хоть "Стебелек".

олап уже какое-то время отмирает, у майкрософта часть что класический олап лет 5 уже не развивается.
имхо проблема у задачки не куда писать, объемы крошечные, а то что по большому счету хранилище строить надо бы. данные явно валидировать и чистить, не понятно что делать если факт пришел а справочника к нему не пришел. как выглядит исправленный факт, что с этим делать ? история то наверно тоже ?
я бы apache spark вычитывал xml и импортировал валидированные данные в файлики колончатой структуры типа parquet или orc. структуры типа снежинка или звезда вроде уже не модно, наверно клал бы в какой-нить вариант Slowly Changing Dimension (SCD). и уже обработанные данные писал бы в рсубд для отчетной системы.

Модно - не модно... :)
Если нужен результат - почему бы не воспользоваться чем то пусть не модным, но тем не менее работающим? И очень-очень похожим на то ТЗ, которое ТС описал?
В первом сообщении топика ведь как раз описание классической структуры "звезда". Если им надо именно такое - почему бы и не дать именно такое? Пытаться всегда использовать самое "модное" - не лучшая идея.
15 мар 19, 13:34    [21833738]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 216
s_ustinov
Модно - не модно... :)
Если нужен результат - почему бы не воспользоваться чем то пусть не модным, но тем не менее работающим? И очень-очень похожим на то ТЗ, которое ТС описал?

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

s_ustinov
В первом сообщении топика ведь как раз описание классической структуры "звезда". Если им надо именно такое - почему бы и не дать именно такое? Пытаться всегда использовать самое "модное" - не лучшая идея.

потому что звезду не сунешь потом бизнес пользователю типа у нас тут self bi, давайте дальше сами. а вот витрины напоминающие таблички какие он у себя в системе видит много больше шансов подсунуть под соусом self bi и не погружаться в адъ репортиков
15 мар 19, 15:33    [21833973]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2108
H5N1
s_ustinov
Модно - не модно... :)
Если нужен результат - почему бы не воспользоваться чем то пусть не модным, но тем не менее работающим? И очень-очень похожим на то ТЗ, которое ТС описал?

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

Pentaho - бесплатная версия есть.
H5N1
s_ustinov
В первом сообщении топика ведь как раз описание классической структуры "звезда". Если им надо именно такое - почему бы и не дать именно такое? Пытаться всегда использовать самое "модное" - не лучшая идея.

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

Оооо...
А можно вот с этого места поподробнее?
Как звезду сунуть пользователям для самостоятельного ковыряния я представляю очень хорошо. Если одна группа мер + измерения в SSAS - подключаем через ексель и говорим пользователям - а это такой pivot table - и они работают и никого не трогают.

А вот как
H5N1
подсунуть под соусом self bi
вот это:
H5N1
обработанные данные писал бы в рсубд для отчетной системы
?
15 мар 19, 19:21    [21834265]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 216
s_ustinov
Pentaho - бесплатная версия есть.

третий эшелон увядающей технологии. я бы не стал тратить время.

s_ustinov
Оооо...
А можно вот с этого места поподробнее?
Как звезду сунуть пользователям для самостоятельного ковыряния я представляю очень хорошо. Если одна группа мер + измерения в SSAS - подключаем через ексель и говорим пользователям - а это такой pivot table - и они работают и никого не трогают.

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

s_ustinov
А вот как
H5N1
подсунуть под соусом self bi
вот это:
H5N1
обработанные данные писал бы в рсубд для отчетной системы
?


в oracle bi и sap bo дефайнются связи между таблицами, пользователь просто накидывает колонки из таблиц в тот же пивот. зачастую не особо понимая как там таблички между собой связанны. подозреваю нечто подобное в любом bi инструменте.
имхо пирожки, графики kpi светофоры гораздо наглядней унылых экселевских таблиц, которые я зачастую прочесть не могу, т.к. без понятия о бизнесе и о чем эти цифры сигнализируют попросту не знаю.
18 мар 19, 16:42    [21836226]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3618
автор
пользователь просто накидывает колонки из таблиц

поржал
нет таких пользователей
19 мар 19, 09:55    [21836883]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2108
H5N1
в oracle bi и sap bo дефайнются связи между таблицами, пользователь просто накидывает колонки из таблиц в тот же пивот. зачастую не особо понимая как там таблички между собой связанны. подозреваю нечто подобное в любом bi инструменте.
имхо пирожки, графики kpi светофоры гораздо наглядней унылых экселевских таблиц, которые я зачастую прочесть не могу, т.к. без понятия о бизнесе и о чем эти цифры сигнализируют попросту не знаю.

Даже если допустить, что пользователи сами смогут "накидывать" колонки (я в свое время любовался на работу пользователей в Access))), не забывайте, что в самом первом топике было два условия - бесплатно и быстро. :)
19 мар 19, 14:41    [21837381]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 216
s_ustinov
H5N1
в oracle bi и sap bo дефайнются связи между таблицами, пользователь просто накидывает колонки из таблиц в тот же пивот. зачастую не особо понимая как там таблички между собой связанны. подозреваю нечто подобное в любом bi инструменте.
имхо пирожки, графики kpi светофоры гораздо наглядней унылых экселевских таблиц, которые я зачастую прочесть не могу, т.к. без понятия о бизнесе и о чем эти цифры сигнализируют попросту не знаю.

Даже если допустить, что пользователи сами смогут "накидывать" колонки (я в свое время любовался на работу пользователей в Access))), не забывайте, что в самом первом топике было два условия - бесплатно и быстро. :)

я думаю все современные bi инструменты примерно одинаково пашут. я работал с oracle bi, но видел что существуют бесплатные редакции почти всех популярных bi инструментов. например "desktop" редакции от майкростофт powerbi и qlik. недавно юзал google data studio. гавно конечно, но быстро накидать колонки в пивот даже это г способно. работает быстро и вполне бесплатно. и что характерно, явно перспективней уже завявшего olap.
19 мар 19, 17:24    [21837598]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2108
H5N1
s_ustinov
пропущено...

Даже если допустить, что пользователи сами смогут "накидывать" колонки (я в свое время любовался на работу пользователей в Access))), не забывайте, что в самом первом топике было два условия - бесплатно и быстро. :)

я думаю все современные bi инструменты примерно одинаково пашут. я работал с oracle bi, но видел что существуют бесплатные редакции почти всех популярных bi инструментов. например "desktop" редакции от майкростофт powerbi и qlik. недавно юзал google data studio. гавно конечно, но быстро накидать колонки в пивот даже это г способно. работает быстро и вполне бесплатно. и что характерно, явно перспективней уже завявшего olap.


Ну кроме bi инструментов (модных), есть и Access, которому 25 лет уже. :)
И он, вот что странно, тоже способен хранить в себе таблички и связи между ними. И для создания отчетов "пользователь просто накидывает колонки из таблиц" - и будет работать.


Но тут есть одна заковыка. Как только мы отойдем от схемы "звезда" - работать с такими данными "не особо понимая как там таблички между собой связанны" уже не получится. А сами по себе данные в транзакционных системах совсем не похожи на звезду.
20 мар 19, 22:02    [21838979]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 216
s_ustinov
Ну кроме bi инструментов (модных), есть и Access, которому 25 лет уже. :)
И он, вот что странно, тоже способен хранить в себе таблички и связи между ними. И для создания отчетов "пользователь просто накидывает колонки из таблиц" - и будет работать.

сомневаюсь. я лет 15 назад запускал access и имея нормальный опыт в родственном фокспро + оракле, линуксах и т.п. вообще нихрена в access сделать не смог. с тех пор майкрософт в развитие access не вложило ни копейки и врядли хоть что-то там поменялось.
в google data studio у меня ушло 2 часа на то что бы соединить 5 табличек mysql и накидать 3-4 репорта. думаю что в случае с access примерно столько же бы у меня ушло на бесплодные попытки настроить odbc коннекцию к mysql через инет, после чего я бы убил заказчика, выяснив что он еще и с андройда дашборды хочет видеть.

s_ustinov
Но тут есть одна заковыка. Как только мы отойдем от схемы "звезда" - работать с такими данными "не особо понимая как там таблички между собой связанны" уже не получится. А сами по себе данные в транзакционных системах совсем не похожи на звезду.

у нас в хадупах нифига не звезды, при этом бизнес пользователи работают с табличками из sap bo, даже в общих чертах не представляя как таблички выглядят и что там за связи. они видят древовидную структуру типа папок и файлов. просто накидывают то что надо в репорт.
звезду тяжко супортить в быстро развивающихся системах, где постоянно что-то меняется. были инет магазин, от туда клиенты сыпят заказы, теперь запустили црм. там те же клиенты. выходи что теперь в звезде надо как-то объединенное измерение воротить. а если это был олап кубик - совсем задница.
20 мар 19, 23:13    [21839000]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Изопропил
Member

Откуда:
Сообщений: 31189
H5N1
я лет 15 назад запускал access и имея нормальный опыт в родственном фокспро + оракле, линуксах и т.п. вообще нихрена в access сделать не смог

И что из этого следует?
20 мар 19, 23:54    [21839007]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 216
Изопропил
H5N1
я лет 15 назад запускал access и имея нормальный опыт в родственном фокспро + оракле, линуксах и т.п. вообще нихрена в access сделать не смог

И что из этого следует?

что интструмент имеет совсем мало общего с BI, который заточен именно под создание репортиков именно неподготовленным пользователем.
21 мар 19, 08:54    [21839120]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Изопропил
Member

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

Вроде ж пользователь подготовленный?
А каково неподготовленному?
21 мар 19, 11:01    [21839287]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2108
H5N1
я лет 15 назад запускал access и имея нормальный опыт в родственном фокспро + оракле, линуксах и т.п. вообще нихрена в access сделать не смог. с тех пор майкрософт в развитие access не вложило ни копейки и врядли хоть что-то там поменялось.

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

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


Надо же, до чего техника дошла...

А вот можно маленький вопрос. У вас там, среди табличек, наверняка ведь и отгрузки и оплаты есть?
Может пользователь, "не представляя как таблички выглядят и что там за связи", накидать следующий запрос:
- Покупатель
- Сумма отгрузок в декабре
- % маржи по декабрьским отгрузкам
- % суммы отгрузок декабря, который еще не оплачен на конец января
- Сумма задолженности по декабрьским отгрузкам на конец января

И отсортировать по убыванию по последнему полю?
Разумеется, все суммы и проценты нужны в разрезе покупателей.
21 мар 19, 12:35    [21839437]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 216
s_ustinov
Ну я чуть больше 20 лет назад первый раз access запускал. На тот момент ни с линухом, ни с нормальными субд не работал. Но - всё получилось.

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

s_ustinov
Надо же, до чего техника дошла...

А вот можно маленький вопрос. У вас там, среди табличек, наверняка ведь и отгрузки и оплаты есть?
Может пользователь, "не представляя как таблички выглядят и что там за связи", накидать следующий запрос:
- Покупатель
- Сумма отгрузок в декабре
- % маржи по декабрьским отгрузкам
- % суммы отгрузок декабря, который еще не оплачен на конец января
- Сумма задолженности по декабрьским отгрузкам на конец января

И отсортировать по убыванию по последнему полю?
Разумеется, все суммы и проценты нужны в разрезе покупателей.

концептуально сможет. как я понимаю бизнес пользователю будут видны папочки Покупатель->Отгрузки->Счета->Оплаты. с этих папочек он сможет накидывать колонки в свою пивот табличку. фильтр на отгрузки = декабрь, фильтр оплаты <= январь.
сумму по счетам и сумму по оплатам этих счетов не вижу сложности накликать. я эти инструменты глубоко не знаю, как там дальше думано не уверен. в oracle bi формулы в колонки можно было писать и через них считать % от соседней колонки. но главное что как там поднизом таблички связанны он и не знает. у него папочки с некими сущностями
21 мар 19, 14:58    [21839680]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2108
H5N1
s_ustinov
Надо же, до чего техника дошла...

А вот можно маленький вопрос. У вас там, среди табличек, наверняка ведь и отгрузки и оплаты есть?
Может пользователь, "не представляя как таблички выглядят и что там за связи", накидать следующий запрос:
- Покупатель
- Сумма отгрузок в декабре
- % маржи по декабрьским отгрузкам
- % суммы отгрузок декабря, который еще не оплачен на конец января
- Сумма задолженности по декабрьским отгрузкам на конец января

И отсортировать по убыванию по последнему полю?
Разумеется, все суммы и проценты нужны в разрезе покупателей.

концептуально сможет. как я понимаю бизнес пользователю будут видны папочки Покупатель->Отгрузки->Счета->Оплаты. с этих папочек он сможет накидывать колонки в свою пивот табличку. фильтр на отгрузки = декабрь, фильтр оплаты <= январь.
сумму по счетам и сумму по оплатам этих счетов не вижу сложности накликать. я эти инструменты глубоко не знаю, как там дальше думано не уверен. в oracle bi формулы в колонки можно было писать и через них считать % от соседней колонки. но главное что как там поднизом таблички связанны он и не знает. у него папочки с некими сущностями

Ну попробуй и нам расскажи. Интересно. Пусть без всяких формул. Просто покупатель, сумма отгрузок декабрь, сумма оплат декабрьских отгрузок до 31.01 включительно. Проценты понятно что можно формулами сделать.
Лично у меня есть подозрение, что без знания структуры данных сделать такой отчет не получится. Там не совсем линейная связь. Но интересно же - может и допилили.
21 мар 19, 15:37    [21839747]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Проектирование БД Ответить