instagibВсем привет!
Есть такой товарищь Dan Linstedt, изобрел методологию моделирования данных Data Vault. Есть ли в России кто-то кто в этом разбирается? Может быть даже является сетрифицированным data vault practitioner?
По моим данным в России нет специалистов по 3NF, а по схеме "звезда", кажется есть один, на Камчатке.

vadiminfoБредятинаПо моим данным ....
А эти данные получены, скорее всего, с помощью запроса, который возвращает часть БД, которой управляет самопальная СУБД, созданная с помощью МУМПСа.
Нет, однозначно из СХОД Oracle, причем ХД сделано в России)))

vadiminfoБредятинаНет, однозначно из СХОД ...
Ну чувствуются направленность результатов куда-то вниз, как бы они СХОДят, а не восходят, потому ясно что не из ВОСХОД они получены.
Исчерпывающий ответ об экспертах по РСХОД (Data Vault) в России. Как всегда))

vadiminfoВ России в основном РСУБД. Ну может в Балабанове или Сывтывкаре появлялись некие МУМПСисты РСХОДами называть РСУБД, чтобы как-то их приопустить до МУМПСа.
Исчерпывающий ответ об экспертах по РСХОД (Data Vault) в России. Как всегда))

Хотя вопросы и к vadiminfo))
NePZ1. РСХОД это ODS? Или что?
Это реляционные системы хранения и обработки данных, предназначенные для программистов (в отличие от СУБД, предназначенных для пользователей).
NePZ2. РСУБД "в основном" не только в России.
Их просто не существует. И это факт))
NePZПока NoSQL и прочие новомодные штуки не решат вопрос согласованности данных широкого распространения эти технологии не получат.
Вопрос согласованности данных решается в этих ДОреляционных технологиях намного эффективнее, чем в реляционных, и никакого широкого распространения они никогда не получат совсем по другим причинам.
NePZДа, есть области, где производительность и масштабируемость намного важнее согласованности данных. Интернет-компании (Facebook, Twitter и иже с ним), биотехнологические компании и прочий хайтек - разведка-оборона и.т.д.
Да, есть задачи, где РСУБД не очень эффективны: задачи обработки сигналов, изображений, массивов текстовой информации и ряд других задач хранения и обработки неструктурированной информации.
За 30 лет мне не удалось обнаружить ни одной задачи, для которой применение РСХОД было бы оправдано. За исключением манипулирование значениями статистических показателей, где алгебра не противоречит семантике.
NePZПроблема заключается в том, что:
1. Это становится действительно актуально, если Вам нужно не просто хранить/быстро извлекать такую неструктурированную информацию, а именно что ее анализировать. А для этого часто нужна довольно сложная математика (и не только математика) и люди (хорошо оплачиваемые), которые владеют нужными знаниями. При этом способы монетизации результатов такого анализа не всегда очевидны. Более того, решая такие задачи с размахом, Вы постоянно рискуете нарваться на законы защиты персональных данных, копирайта и тому подобные вещи.
Вы, хотя и просто философствуете, но - на правильном пути в поисках хоть какого-то приложения для РСХОД. И, заодно, правильно подметили фундаментальное преимущество для программистов реляционной технологии - при ее использовании не то, что сложные вычисления, а просто извлечь из БД фамилию человека невозможно без помощи программиста))
NePZ2. Данных должно быть действительно много. Потому что, когда данных немного, то для обработки информации можно использовать не то, что РСУБД, а старый-добрый табличный редактор (Excel, например).
Совсем уж банальный и неубедительный аргумент "много/немного".
NePZ3. NoSQL это не технология, и не платформа. Это целый букет совершено разных решений
- документо-ориентированные базы данных (типа MongoDB);
- объектно-ориентированные базы данных (типа Cache);
- экзотика типа баз данных, основанные на графах (типа Neo4j);
Каждое из этих решений хорошо подходит только для строго определенного круга задач. В погоне за серебряной пулей Вы заведете в организации такой зоопарк, что работать с ним будем весьма и весьма проблематично, если у Вас нет армии программистов и пользователей - гиков. Потому что есть Гугл, facebook или АНБ, а есть обычные заводы или банки, для которых ИТ - это шибко непрофильный вид деятельности.
Опять-таки, хороший программист легко может освоить новую технологию. Но смогут ли это сделать конечные пользователи и во что это станет? Сможете ли Вы безболезненно сменить подрядчика, если технология не очень распространена?
А причем здесь NoSQL??? Что Вы под этим понимаете? Не декларативный язык запросов? А разве пользователем нужен язык программирования??? Или Вы имеете в виду именно алгебру? Тогда да, есть одно приложение, для которого некий аналог РСХОД выглядит оправданно, я о нем написал выше.
NePZ4. Освоить инструмент и хорошо знать инструмент - это одна большая разница.
Большая часть модных технологий - сырая до невозможности. Как только Вы начинаете делать на этой чудо платформе-инструменте - решении что серьезное, всплывает, что Вы или в очередь более N файлов зарядить не можете из-за ограничений компонента, который за бэкапирование отвечает, или что при M потоках у Вас ноды валятся и нужно напильником службы выпиливать, или что дрова кривые, или что один из служебных процессов модной штуки валит Вам ... (нужное вписать) третьего приложения, с которым его надо интегрировать. Понять масштаб последней неприятности может только человек, который запрашивал HotFix у поставщика этого модного решения. Не вдаваясь в подробности - это анальный ахтунг.
С новомодными всегда такие трудности возникают - это очевидно.
NePZ5. Какое отношение все это имеет к Data Vault? :)
Поскольку Вы все это написали - Вы и можете объяснить. А вот РСХОД имеет самое непосредственное отношение к Data Vault. Поскольку Data Vault - это очередная попытка приспособить-таки РСХОД для решения хотя бы какой-то практической задачи, причем примерно такой, о которой я и написал выше))

NePZЧестно: не понял. Можете на примере пояснить, что такое СУБД, предназначенная для пользователей, и что такое СХОД, предназначенная для программистов? Первый раз о такой классификации слышу. Потому что слова "система", "обработки данных", "...для программистов" у меня скорее с ETL-машинами ассоциируются.
"СУБД для пользователя" Вы называете способы обращения к данным, которые не требуют от пользователя написания SQL, MDX, XQuery и.т.д. запросов? Или что-то иное?
Просто мне для понимания: Oracle - это РСХОД или нет?
Oracle - конечно, СХОД. Причем, не вполне Р. Она никогда не станет СУБД, потому что в ее основе лежит реляционная технология, что приводит к неизбежности известной архитектуры:
13577413
Чувствуется, что Вы мало знаете в области теории и проектирования БД, и не понимаете основных принципов БД:
13254920
13755686
13545785
14020991
14026636
Потому что общаетесь, в основном, с ограниченными людьми типа vadimifo, которые даже реляционную теорию не понимают.
СУБД предполагает интерактивный интерфейс, основанный на семантически развитой МД, поэтому реляционные системы никогда не станут СУБД.
NePZ Потому что если да, то я не понимаю второе предложение:
Бредятина...мне не удалось обнаружить ни одной задачи, для которой применение РСХОД было бы оправдано
Потому что для хранения данных о банковских транзакциях, например, ничего лучше реляционных систем с ACID я не видел.
Ничего нелепее не может быть, чем РСХОД для банковских транзакций) Если Вы разработчик, то, конечно, ничего лучше. Ведь применение любой СХОД требует перманентного программирования, и любой программист кровно заинтересован в такой технологии))
NePZМне в проектной практике доводилось сталкиваться с очень разными вещами:
- хранением гигантских объемов контента, с необходимостью быстрого извлечения нужного файла,
- задачами OCR/ODR, где текст нужно распознать за секунды или доли секунды,
- с биометрическими системами верификации, где из графического файла нужно извлечь какую-то нетривиальную информацию,
- с задачами (антифрод, если интересно) где какой-то набор информации надо на лету сопоставить с десятками миллионов других наборов и все крутится в оперативке.
- с задачами поиска данных в огромных массивах текстовой информации.
Каждая из вышеперечисленных задач требовала специфичных подходов и решений и конечные пользователи в потроха этих систем действительно не лезли. Они видели на экране нужную им картинку, текст, наборы соответствий и.т.д.
Разумеется, никому не нужно "лезть в потроха"))
NePZК чему все это: я просто не понимаю, что Вы пишете. Возможно, мы об одном и том же говорим.
Нет, не об одном и том же. Потому что, я-то, как раз, прекрасно понимаю, что Вы пишете.
NePZВозвращаясь к теме:
Бредятина Поскольку Data Vault - это очередная попытка приспособить-таки РСХОД для решения хотя бы какой-то практической задачи
Глубоко ИМХО, но когда я столкнулся на практике с Data Vault, то я видел в этой методологии лишь попытку ответить на вопрос "как лучше уложить большие наборы хорошо структурированных данных в корпоративном ХД, чтобы снизить издержки на управление жизненным циклом этого самого ХД". Ударение на словах "много данных" и "гибкость при доработке".
Здесь нет никаких противоречий в наших взглядах на РСХОД/Data Vault.
NePZКасательно изначального вопроса ТС, то ребята из I-Teco произвели на меня впечатление людей, которые вполне разбираются в этой самой методологии. Так что правильный ответ будет: "Да, есть".
Отлично!

vadiminfoЭто ахинея от МУМПСиста ЧАЛа (он же Бредятина, что вполне соответствует содержанию его текстов). Никакого смысла в этом нет кроме опустить РСУБД до уровня МУМПСа (который могие за СУБД не считают и уже потому не конкурент ). А так по его задумке РСУБД тоже как и МУМПС не СУБД. И можно его подбрасывать где обычно юзают РСУБД.
Ложь, глупость и подлог. Так всегда получается, когда нечего сказать по существу)) Я ни разу не "мумпсист". MUMPS не поддерживает никакую МД вообще и поэтому ее нельзя сравнивать с РСХОД в принципе, и, тем более, куда-то подбрасывать))
vadiminfoТам, вроде, кто-то повелся, и ЧАЛ там что-то подбросил в свое время где-то в районе 2004 года. Впрочем, он сам признал, что в Балабанове 1С. Т.е. там уже все поняли и юзают РСУБД
Ложь глупость и подлог. Так всегда получается, когда нечего сказать по существу)) Ни одной РСУБД в природе не существует, и "юзать" их невозможно))

[quot vadiminfo]Ложь глупость и подлог. Так всегда получается, когда нечего сказать кроме ахинеи. Вам как начинающему в РСУБД могу посоветовать РСУБД MySQL.
Ложь, глупость и подлог. Так всегда получается, когда нечего сказать по существу)) Эту глупость про роль "ключей" в Data Vault Вы повторяете уже во второй раз)))
vadiminfoТ.е. дошло до Вас что выбор МУМПСа был ошибкой? Его можно выбросить из технологий БД?
Эту глупость про роль "ключей" в Data Vault Вы повторяете уже в третий раз)))

vadiminfoЗначит все таки ЧАЛ незадачливый пиарщик МУМПСа, раз это глупость, что оный был ошибкой молодости.
Эту глупость про роль "ключей" в Data Vault Вы повторяете уже в четвертый раз)))
vadiminfoИть "специалист по БД должен знать МУМПС"? А все остальное де мол не СУБД? У их нет этих ЧАЛовских "приципов БД".
Эту глупость про роль "ключей" в Data Vault Вы повторяете уже в пятый раз)))
vadiminfoК этому ить сводится вся сверхзадача ЧАЛа здесь?
А теперь ЧАЛу дела нет до МУМПСа "как тому цыгану до лошади" (С)?
Ловкач. Ох ловкач.
Эту глупость про роль "ключей" в Data Vault Вы повторяете уже в шестой раз))) Ничего не поняли в Data Vault. Давайте, штудируйте:
13254920
13755686
13545785
13577413
14020991
14026636

vadiminfoМне то зачем эта ахинея от ЧАЛа?
Ни в Балабаново, ни в Сывтывкар не собираюсь. Поржать? Так это уже повторенная 100 раз хохма. ЧАЛ ее куда тока не засунул.
Эту глупость про роль "ключей" в Data Vault Вы повторяете уже в седьмой раз))) Ничего не поняли в Data Vault. Давайте, штудируйте:
13254920
13755686
13545785
13577413
14020991
14026636

vadiminfoДык вроде выучил эквивалент всего наивняка на уровне 1 класса:

Эту глупость про роль "ключей" в Data Vault Вы повторяете уже в седьмой раз))) Ничего не поняли в Data Vault. Давайте, штудируйте:
13254920
13755686
13545785
13577413
14020991
14026636