Не хочется выступать в роли неконструктивного критика, поэтому не буду придираться к каждому пунту (все не без греха), но вот фразы,
Какие действия необходимы для создания полноценной СУБД
В СУБД, созданной под конкретные задачи своими силами, доступ получает клиент или администратор. В его руках все рычаги и инструменты управления.
Самостоятельное создание СУБД особенно актуально на текущем этапе геополитики и экономического развития страны, когда практически все сферы жизнедеятельности направлены на импортозамещение.
если честно, глобально режут глаз, когда применяются в контексте проектирования и разработки платформы данных предприятия (построенной на базе в т.ч. и СУБД) с дальнейшим ее развертыванием и конфигурированием. Все-таки создание собственной СУБД - "это другое".
Не хотелось бы пополнять армию "хейтеров". А мой комментарий явно покажет, что я в армии задротов уже давно. Но выскажу свое мнение не претендуя на глубокую экспертность.
Невозможно ввести человека в суть баз данных без четкого понимания математической базы которая легла в основу продукта, ставшего потом коммерческим, независимо от того возможно ли физически эту теорию воплотить в жизнь.
Невозможно понять декларативную природу SQL не владея логикой предикатов и базовыми знаниями теории множеств (а это очень важно - использование декларативного стиля написания это первый шаг к оптимизации запросов). Не понимая, природу деревьев, в частности B-дерева, невозможно рассуждать о преимуществах индексных структур, хотя на B-tree тоже свет клином не сошелся.
Опять же нельзя упустить, что колончатые базы, как правило, используются для доступа к данным через OLAP-ориентированные запросы к денормализованным структурам данным (отсылка к реляционной теории и нормализации) и почему в этом случае мы получаем максимальный эффект от колончатой природы хранения данных. Причем использование одного из диалектов SQL, по прежнему остается востребованным интерфейсом взаимодействия пользователя с структурами хранения данных в колончатых СУБД.
Я ни в коем случае не утверждаю, что статья не имеет права на жизнь, но я бы больше назвал ее "Введение в базы данных для менеджера", когда нам надо на пальцах объяснить нетехническому человеку, за что он должен заплатить деньги. Увы, как введение для начинающего разработчика, она пока не дотягивает, поскольку не отвечает на вопросы "как" и "почему". Как по мне для технарей описание дорожной карты процесса обучения было бы гораздо более полезным введением (с обоснованием по каждому пункту, почему он должен приложить усилия для приобретения предложенных знаний). Но это сугубо ИМХО.
Пока проект находится на стадии создания прототипов отдельных компонентов архитектуры.
Но то, что далеко не все концепты, которые изначально казались красивыми, перспективными и передовыми, взлетели это факт. Хотя, на то он и исследовательский процесс, чтобы отработать все варианты в том числе и тупиковые.
То что мы все умрем понятно. Что делать чтоб не сразу? Понятное дело, что готовых рецептов нет и как раньше уже не будет. То что в чем-то конфигурация соответствует комбинации из 4-х букв из которых нельзя собрать слово вечность, мы разобрались. Надо хотя бы попытаться составить высокоуровневую версию дорожной карты выхода из ситуации от которой можно начинать плясать, как говорится по аджайлу )
Обслуживание парка уже проданной профессиональной техники тоже денежку приносит. Причем в этом сегменте (в отличие от одноразовых бытовых погремушек), жизненный цикл оборудования долгий. Так что всегда найдется охотник получить готовую сервисную инфраструктуру за цену ниже ее реальной рыночной стоимости (учитывая в каких условиях совершается сделка). Ну а дальше будет видно насколько верно покупатель оценил риски...
Не хочется выступать в роли неконструктивного критика, поэтому не буду придираться к каждому пунту (все не без греха), но вот фразы,
если честно, глобально режут глаз, когда применяются в контексте проектирования и разработки платформы данных предприятия (построенной на базе в т.ч. и СУБД) с дальнейшим ее развертыванием и конфигурированием. Все-таки создание собственной СУБД - "это другое".
Не хотелось бы пополнять армию "хейтеров". А мой комментарий явно покажет, что я в армии задротов уже давно. Но выскажу свое мнение не претендуя на глубокую экспертность.
Невозможно ввести человека в суть баз данных без четкого понимания математической базы которая легла в основу продукта, ставшего потом коммерческим, независимо от того возможно ли физически эту теорию воплотить в жизнь.
Невозможно понять декларативную природу SQL не владея логикой предикатов и базовыми знаниями теории множеств (а это очень важно - использование декларативного стиля написания это первый шаг к оптимизации запросов). Не понимая, природу деревьев, в частности B-дерева, невозможно рассуждать о преимуществах индексных структур, хотя на B-tree тоже свет клином не сошелся.
Опять же нельзя упустить, что колончатые базы, как правило, используются для доступа к данным через OLAP-ориентированные запросы к денормализованным структурам данным (отсылка к реляционной теории и нормализации) и почему в этом случае мы получаем максимальный эффект от колончатой природы хранения данных. Причем использование одного из диалектов SQL, по прежнему остается востребованным интерфейсом взаимодействия пользователя с структурами хранения данных в колончатых СУБД.
Я ни в коем случае не утверждаю, что статья не имеет права на жизнь, но я бы больше назвал ее "Введение в базы данных для менеджера", когда нам надо на пальцах объяснить нетехническому человеку, за что он должен заплатить деньги. Увы, как введение для начинающего разработчика, она пока не дотягивает, поскольку не отвечает на вопросы "как" и "почему". Как по мне для технарей описание дорожной карты процесса обучения было бы гораздо более полезным введением (с обоснованием по каждому пункту, почему он должен приложить усилия для приобретения предложенных знаний). Но это сугубо ИМХО.
В любом случае еще рано о чем либо говорить
Но то, что далеко не все концепты, которые изначально казались красивыми, перспективными и передовыми, взлетели это факт. Хотя, на то он и исследовательский процесс, чтобы отработать все варианты в том числе и тупиковые.
То что мы все умрем понятно. Что делать чтоб не сразу? Понятное дело, что готовых рецептов нет и как раньше уже не будет. То что в чем-то конфигурация соответствует комбинации из 4-х букв из которых нельзя собрать слово вечность, мы разобрались. Надо хотя бы попытаться составить высокоуровневую версию дорожной карты выхода из ситуации от которой можно начинать плясать, как говорится по аджайлу )
Обслуживание парка уже проданной профессиональной техники тоже денежку приносит. Причем в этом сегменте (в отличие от одноразовых бытовых погремушек), жизненный цикл оборудования долгий. Так что всегда найдется охотник получить готовую сервисную инфраструктуру за цену ниже ее реальной рыночной стоимости (учитывая в каких условиях совершается сделка). Ну а дальше будет видно насколько верно покупатель оценил риски...