Бредятина,

Ничего не понял :)
Как пользователи могут владеть данными, если они ими только пользуются? Вот вы написали пост - разве вы владеете его представлением в базе форума или отвечаете за сохранность этих данных, в том числе в долговременной перспективе?

Расшифруйте DOA/IOA - гугль не в курсе этих аббривеатур.

"Избавиться от приложений полностью" - вы сторонник подхода "пихаем всё в СУБД, включая веб-сервер"? Видел я и такие проекты...

Что конкретно читать? Если вы про те 73 страницы - то пока не набрался смелости, чтобы выуживать из того болота ценные факты :-)

Бредятина,

Пожалуйста, ответьте на предыдущий пост.

Что касается ОП - я думал, что преимущества очевидны :). Простота в использовании со стороны приложений и быстродействие. Меня больше недостатки интересуют, насчет преимуществ я вполне в курсе.

Бредятина,

ОП = OP=open post
Огромное спасибо за расшифровки, наконец-то нашел внемяемую литературу по проектированию хранилищ данных.
Насчет преимуществ. Возьмем, например, базу страховых полисов. Полисов бывает большое кол-во типов, у каждого типа куча информации, которая в нем хранится, причем часть этой информации опциональна, причем опциональность зависит не от типа полиса, а от его данных.

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

Альтернатива? Одна таблица с тремя полями: id, номер полиса, clob с json-ом.

Плюсы:
- простота и скорость вставки и чтения полисов. никакого random io, никаких джойнов, никакой необходимости вытаскивать полис по частям, т.к. json пусть и сложен по формату, но невелик по объему - не больше 5 кб. Для пущей эффективности можно его сжимать или даже использовать двоичный формат (хотя это может быть плохим решением - см. ниже)
- простота приложения, которое с этой базой работает. несколькими строчками можно достать из базы и развернуть полноценный объект полиса

Проблемы и пути их решения:
- справочники. Большая часть справочников не слишком велика и не обновляется оперативно, так что можно их кешировать на стороне приложения. Если обновляется оперативно - обновлять через другое приложение, которое предоставляет возможность подписки всем желающим. Если справочник реально огромен - делать селект из приложения по id. Если еще и roundtrip большой до базы... придется эти айдишники выносить из json в нашу таблицу и джойнить при извлечении полиса.
- Юзер хочет список полисов, отсортированный и отфильтрованный по хитрым, юзерским критериям. Используем внешний индекс, закачивая в него данные в формате, заточенном под требования пользователя. Т.е. с данными, по которым будет идти поиск + данными, которые надо показывать в списке полисов.
- Экспорт данных в другие системы? ETL уже не катит, да. Экспорт должно делать специальное приложение, которое загрузит полис, преобразует его и зальет куда надо.
- Отчеты и аналитика? Если используется OLAP, то у него все равно отдельная база звездой, см. предыдущий пункт про экспорт. Если обычная база, то при ее проектировании можно учитывать только задачи аналитики - это сильно упростит задачу. Если данных реально много и юзер может подождать несколько минут, то из исходной базы данные отлично переливаются в Hadoop.

Проблемы, которые я не уверен, как решать:
- Consistency. Поиск может не возвращать свежайшие данные, экспорт будет экспортировать не совсем снапшот(частично решается версионностью записей с таймстампом)
- Управление данными. Уже не посадишь sql-щика вычищать мусор из базы. И если данные в классической СУБД почти самодокументируемы, т.е. следующее поколение разработчиков, в теории, сможет их использовать, то json, а, тем более, двоичный формат потребует тщательного документирования.

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


Фух :) Надеюсь, это внесет какую-то ясность.

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

Кот Матроскин,

"Неизбежно" - неудачное слово.
Простейший пример - если мы добавили новое поле в таблицу, с дефолтом разумеется, чтобы инсерты не сломать. А приложение по этой таблице делало select * from ... Чем не повод сломаться?

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

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

Кот Матроскин,

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

Бредятина,

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

"Все данные в одной таблице" а-ля денормализация - очень популярный способ упрощения базы, НО плохо применим к отношениям один-ко-многим. В итоге появляются кадавры Fio1, Fio2, Fio3 и в итоге упираются в макс. кол-во столбцов в таблице. Плюс без пол-литры не поймешь, какие поля в данной строке используются, а какие не очень.

Бредятина,

Тоже не понял фразу про программирование и доработки. "добавить в индекс новое поле" - это как раз доработка. Конфигурации индексатора и подсистемы экспорта данных в этот индексатор. Плюс гуй.

Как раз есть) Вот что гугль говорит с ходу про оракл:
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:53174778859588

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

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