Интересно. Но я вот только не пойму, зачем реляционную CEБД PostgreSQL использовать таким образом - хранить сырые объекты в JSON? Можно ведь использовать объектную NoSQL СУБД - она специально сконструирована под такое использование. Или - с помощью какой-нибудь ОРМ либо вручную отображать объекты на обычные поля обычных таблиц (хотя бы частично, для тех полей, по которым поиск и фильтрация часто производятся)?
Или хранение JSON и манипуляции с ним - это очень маленькая часть большого проекта, которому в остальной части требуется именно реляционная СУБД?
Ну, можете посмотреть и другие примеры других авторов на том же сайте - Мараховский там там не один такой.
Но кое в чём вы всё-таки были правы: журналисту заплатит тот, кто заинтересован. Не правы вы были в другом: в том, что читатели в принципе не являются теми кто платит, платежеспособной аудиторией.
PS Лично мне платная подписка по своему принциипу нравится больше, чем нынешняя модель финансирования публикаций через рекламу. Но чисто конкретных своих денег мне, конечно, жалко.
Журналисту могут заплатить и читатели, через сервис платных подписок, типа Спонсор, Бусти и т.п. И ведь платят, что характерно! Вон, есть такой журналист Мараховский, он на Спонсоре сейчас пишет. Денег с этого немало получает (можете посмотреть - там статистика открытая), и при этом доволен, как слон (постоянно об этом упоминает), что деньги есть, а начальства нет.
Другой вот вопрос - как обычному журналисту свое имя раскрутить, чтобы стать хорошим журналистом, на которого подписываются?
Ну, и самое главное, что проект Samba AD изначально был направлен на создание совместимости с Windows, а не разработку нативного доменного решения для Linux, поэтому участникам Samba Team навсегда уготована роль догоняющих.
Пардон, что там догонять-то?
Вы в курсе, что текущие функциональные уровни домена и леса AD DS для новейшей на сечас версии Windows Server 2022 - то, что определяет возможности AD DS как распределенной базы данных учетных записей - это уровни Windows Server 2016. Что касается клиентов, то они в большинстве случаев нечуствительны даже к таким изменениям этих самых функциональных уровней. То есть, спецификация продукта под названием Active Directory Domain Services не меняется уже почти 8 лет. Неужели за это время нельзя было (при нормальной работе) проапгрейдить роль догоняющих на роль догнавших и на это успокоившихся?
Ну, и прошу вас прояснить вопросы, которые у меня возникли к авторам обзора другой альтернативной службы каталога и централизованной аутентификации (ссылка), потому что упомянутые там возможности вашего продукта мне из этого обзора непонятны
Из обзора совершенно непонятно, что поддерживается каждым продуктом из возможнойстей AD, кроме базовых: каталог LDAP, хранение пользователей и групп в рамках одного домена, доступ к спискам пользователей и групп по протоколу Netlogon, аутентификация с передачей авторизационной информацией по протоколам Kerberos и NTLM. Интересует: -возможность изменения содержимого каталога параллельно на нескольких контроллерах домена с репликацией этих изменений на другие контроллеры и разрешением конфликтов при репликации; -возможность хранения в одном каталоге учетных записей и групп для нескольких разных доменов (поддержка леса доменов) с автоматическими доверительными отношениями между этими доменами; -возможность установки доверительных отношений через протоколы NTLM (внешнее доверие) и Kerberos (межлесное доверие); -возможность репликации с контроллерами AD под Windows (поддержка соответствующего протокола репликации)
IMHO в техническом обзоре всё это должно быть.
PS Особенно интересует первый пункт: возможность изменения содержимого каталога параллельно на нескольких контроллерах домена с репликацией этих изменений на другие контроллеры и разрешением конфликтов при репликации. Потому что в те времна, когда я смотрел возможности Netscape Directory Server, этой возможности в нем не было.
Не совсем так. Я изучал этот вопрос где-то лет двадцать назад. И тогда считалось, что для описания "пожеланий заказчика" - точнее, предметной области бизнеса, функционирования предприятия и т.п. - нужно делать описания не на общечеловеческом языке, а с помощью специальных средств, таких как диаграммы САДТ (IDEF0) для функционального описания, диаграммы "сущность-связь"(IDEF1) для описания данных предприятия и т.п. Был, как минимум, один целый набор методологий (IDEF) для разработки таких описаний.
Изучал я по книгам и статьям в журналах, естественно: в фирмочке, где я тогда работал, таких сложностей не требовалось. Хотя кое-что из этого инструментария использовал - к примеру автоматическую генерацию схемы БД по методологии "сущность-связь" программой ERWin
Как с этим в нынешней реальности - не знаю. Но, судя по таким вот статьям - не очень хорошо, снизить сложность разработки и требований к квалификации программистов, непосредственно пишущих код, путем отвязывания непосредственно разработчиков от неточностей и неясностей предметной области, выяснение котторых - задача аналитиков, не получилось.
А как в этой МОС ЕС было с большими и маленькими буквами - в именах файлов и пр.? Ведь в во всех сортах *nix они всегда отличались, и это было важно, а вот на ЕС-7927 с руссифицированным под ДКОИ знакогенератором - совсем нет (отличались они на польских Mera, которые тоже были формально ЕС-7927, но в них не было русского шрифта, зато были маленькие латинские буквы).
Я это не просто так спрашиваю: это была та причина, по котрой в том ВЦ, где я тогда болтался (считал свою и физику и потихоньку хакерствовал) какая-то такая Unix-подобная система (по-моему - из Курчатника, т.е. ДЕМОС) была зарублена, хотя во всем остальном она никому не мешала, потому что там в качестве основной ОС IBM VM/SP был (это - гипервизор), а под ним что угодно можно было запускать (например, тот же VM/SP - я так развлекался, если чо).
Тут нет смысла использовать Volatile.Read, так как кэш CPU...
Тут неприятности могут случиться ещё до кэша: чтение значения переменной _random и проверка его на null уже были сделаны чуть ранее, и компилятор/JIT может решить, что второй раз проделывать ту же работу незачем.
_Volatile.Write_ так же нет смысла тут использовать, так как нет инструкций для перестановки внтури lock, а после lock все содержимое кэша CPU будет перенесено в память.
Тут вопрос, когда оно будет перенесено и увидит ли вовремя это новое значение поток, пытающийся выполнить инициализацию параллельно на другом процессоре? Без Volatile таких гарантий, в общем случае, нет, а модели памяти процессоров и синхронизации кэшей - они в этом плане различаются. Да ещё и в будущем могут различия в неблагоприятную сторону появиться: синхронизация кэшей - операция дорогая, и у разработчиков железа всегда есть соблазн попытаться на этом сэкономить. Так что IMHO, как это часто бывает при разработке в условиях параллельности, лучше заранее соломку подстелить в виде гарантий наличия барьеров, чем отлавливать потом плавующую ошибку синхронизации.
Я не буду тут вдаваться в подробности, как возникает стоимость, и как сочетаются между собой ваши приверженности одновременно к трудовой теории стоимости (основе экономических воззрений марксистов) и к неолиберализму. Хотя мне тут есть что сказать - начиная с опровержений марксизма со стороны маржиналистов.
Мне сейчас важно, что вы таки имели в виду меновую стоимость , а не потребительную (т.е. само благо). Тогда мое возражение - а оно относится именно к меновой стоимости, чем бы конкретно она не определялась - остается в силе: оказывается, что меновая стоимость в течение времени не сохраняется. И это - принципиальное следствие технического прогресса (который вы, надеюсь, не отрицаете).
Ну и как в таком случае может быть справедливым тезис, на котором вы основыветесь - что деньги могут иметь неизменную покупательную способность?
Ну, про стоимость много разных вопросов задать можно. Первый - в чем ее мерять? В конкретном благе (а тогда сразу вопрос - как сопоставлять разные блага?)? В необходимых (иначе - неустранимых) издержках на производство данного конкретного блага (типа затрат труда в трудовой теории стоимости)?
Вопрос не просто так, потому что одно и то же благо с течением времени может потребовать, ну, совершенно разных издержек на свое производство: технический прогресс идёт, однако. Один из наиболее ярких примеров - алюминий: чушка алюминия где-нибудь в 1880-м году требовала гораздо больших затрат на ее создание, чем четверть века спустя - после изобретения получения электролизом глинозема в криолите и появления дешевых источников электроэнергии (это - ещё одна цепочка изобретений и усовершенствований).
Так что, не знаю, интуитивно оно, или нет, но, в общем случае - неверно.
Первое чтение надо делать volatile, без этого никак.
Если хорошо подумать, то в данном случае, когда изменение поля возможно только в одном направлении, с null на уже созданный объект (если я правильно понял это из фрагментов кода в статье) - совершенно необязательно. Если содержимое поля, сейчас или когда-то ранее, уже оказалось непустым значение, то, при условии правильно расставленных барьеров внутри lock-блока, другому значению там взяться будет неоткуда. А оптимизация благодаря этому может оказаться существенной. Но вот внутри lock-блока все должно быть с надлежащими барьерами - и чтение, и запись, - примерно так:
if (Object.ReferenceEquals(_random, null))
{
lock (_lockObject)
{
if (Volatile.Read(ref _random) == null)
{
Volatile.Write(ref _random, new Random());
}
}
}
Но, возможно, лучше действительно не думать, а использовать стандартные средства библиотеки языка для отложенной инициализации. А если таки понадобится оптимизация - подумать о ней потом, благо поле - частное, и на интерфейс библиотеки оно не повлияет никак.
PS А ещё я не люблю слово "анти-паттерн". Потому что применяющие его зачастую стремятся просто запретить использовать объявленное "анти-паттерном" решение, а не задуматься, применимо ли оно в конкретной задаче.
По-моему, вы не слишком осведомлены в истории появления ООП. "На заре" - это лет сорок назад, по крайней мере первый язык ООП- Smalltalk - был упомянут ещё в статье про Настоящих Программистов (тех самых, которые не используют Паскаль), вышедшей уже более 40 лет тому назад.
Не проще ли хранить в базе сразу объекты, например, классы Java со всеми полями и методами в memory likre model
Хранить-то можно что угодно - вопрос как с этим работать. Например, что делать, когда потребуется поиск/фильтрация/сортировка по полям? Ответ известен - создавать индекс, но индексировать поля однородных записей в таблицах значительно проще и эффективнее, чем поля объектов произвольной, возможно - сложной, структуры. Или - как хранить объекты, являющииеся полями других объектов? Если - как части объектов, в которые они входят, то получается денормализованная структура, со всем присущими ей аномалиями - обновления и т.д. Ели как ссылки на вложенные объекты - то как поддерживать эти ссылки. И т.д.
Если для вашего проекта объектная БД подходит - используйте. Но это решение - тоже не универсальное. Как и противоположное - не использовать в сколь-нибудь сложных проектах объекты вообще, даже в коде: видел и такое в комментариях ув. @SpiderEkbк недавней статье, вызванных его опытом работы с высокнагруженным ядром банковской системы крупного банка. Даже в коде, в памяти - а уж использовать в таких проектахобъектных хранилищ данных, и тянуть, фигурально выражаясь, когда нужен только банан, ещё и обезьяну, которая его держит, и джунгли, где обезьяна живет - это вообще за всякие рамки входит.
Короче мое мнение: всякое решение имеет ограниченную область применения. И подобрать решение для конкретной задачи - это уже отдельное умение. Использовать для этого такие грубые шаблоны, как вы тут пишете - это неуместно.
Ну да, sqlite — это хорошее современное воплощение хорошей старой идеи. Самой идее-то — лет 30, как минимум. В первой половине 90-х на ПК были широко распространены встраиваемые прямо в приложение файловые базы данных на реляционной основе (то есть, сделанные из таблиц и индексов) — dBase+Clipper, Paradox и пр… И NoSQL — с сетевой моделью данных, сейчас бы ее отнесли, наверное, к графовым — БД тоже была: dbVista, переименованная впоследствии в Raima Database Manager. И библиотеки для работы с файлами формата таких БД тоже были: CodeBase — для работы из C с форматом dBase и Clipper (этой сам активно пользовался), потом — IDAPI, она же — BDE (Borland Database Engine), которая могла работать и с файловыми форматами БД (Paradox и dbBase), и с SQL-серверами. С SQL, правда, было бедно: на ПК для него памяти было откровенно мало (особенно в DOS), потому все больше пользовались навигационным доступом (это — к отдельным таблицам, по одной записи, можно искать по индексу), но где-то во второй половине 90-х SQL стал вполне поддерживаться: в частности (из того, чем я пользовался сам), прикрутили SQL к BDE в качестве встроенного в него самого.
Ну, и сейчас SQLite — не единственная встроенная БД. Есть, как минимум, Embedded MS SQL — он используется для разработки, но вот разрешает ли MS его использовать для программ на ПК — это я не в курсе.
PS А ещё где-то мимо меня прошел MS Access: к нему тоже можно было обращаться из программ через ODBC или OLEDB/ADO, но с ним я никогда в таком режиме не работал.
Нет. Для самой начальной загрузки использовался интерфейс работы с диском из BIOS (Int 13, для этого с самом контроллере диска было ПЗУ для расширения BIOS), через него загружался указанный в конфигурации (в реестре с типом запуска start= boot) драйвер ядра NT и дальше шла работа с диском через этот драйвер. Реестр просматривался загрузчиком тоже через BIOS, а путь к установленной Windows NT был прописан в файле boot.ini в совершенно нестандартном для мира ПК формате ARC.
При установке установщик пробовал все известные ему драйверы диска, если же ни один не подходил — требовал дискету (именно дискету!) с нужным драйвером.
Впрочем, были способы встроить такой драйвер в дистрибутив (например — программой nLite)
Эта схема загрузки использовалась до Win2K3 Srv включительно, а современная схема появилась только в Vista
Возникает соблазн сдвинуть эту задачу еще на уровень ниже, то есть на уровень БД.
Вроде как, между уровнем БД и уровнем бизнес-логики часто бывает уровень абстрактного хранилища объектов: хранилище отображает объекты, с которыми работает бизнес-логика, на операции уровня БД. И ORM как раз этим и занимается.
Так что сдвигать задачу на уровень БД — ее схемы и операций с ней — в общем случае совсем не обязательно. При низких требованиях к производительности можно обойтись ORM и тем самым сэкономить на персонале (а бизнес экономить любит, да), которому не нужно уметь работать на уровне БД: знать SQL и, тем более, язык хранимых процедур конкретной БД, и, тем более, читать планы выполнения запросов, думать о необходимости индексов, избегать излишних блокировок и заниматься прочими обязанностями DBA.
Бизнес-логика же при наличии такого абстрактного хранилища в виде ORM будет работать с объектами вполне статических типов (не скажу за все ORM, но конкретно EF это более чем позволяет: это его основной режим работы).
Все это замечательно здравствует, пока не возникают нагрузки, для которых требуется оптимизация, хоть какая-то. Но это уже другая история.
А если вспомнить исходный комментарий ветки от ImagineTables то, безотносительно к GraphQL, схема данных желательна (ибо дисциплинирует), но, накрайняк, без нее можно обойтись (например, так обстоит дело в мире XML). Проверять же запрос на правильность формулирования можно и при его приеме на севере. Правда тогда есть риск возникновения разных представлений о схеме данных у разных людей — и вот тут-то схема и проверка по ней станет настоятельно необходимой.
Просто смапить не выйдет из-за разных типов данных.
А если не просто, а через ORM?
Я вот смотрю на примеры возвращаемых результатов через GraphQL и у меня перед глазами прямо встают типы DTO для Entity Framework (это ORM для C#, если кто вдруг не в курсе). Остается только прикрутить библиотеку преобразования запроса c языка GraphQL в LINQ — и можно работать с реляционной БД, не сильно при этом задумываясь.
Кроме того, некоторые особенности функционального стиля (чистые функции, иммутабельные переменные, композиция функций) позволяют легче распараллелить и отлаживать код.
Это вы про C# или вообще?
Если про C# то покажите мне способ получиь гарантию от компилятора, что делегат, который мне могут передать в мою функцию, не может не быть чистой функцией. Я такого способа, например, не знаю. А в отсутствии этой гарантии от компилятора функциональное программирование превращается в «функциональщину», которая ничего такого прекрасного не позволит.
Интересно. Но я вот только не пойму, зачем реляционную CEБД PostgreSQL использовать таким образом - хранить сырые объекты в JSON? Можно ведь использовать объектную NoSQL СУБД - она специально сконструирована под такое использование. Или - с помощью какой-нибудь ОРМ либо вручную отображать объекты на обычные поля обычных таблиц (хотя бы частично, для тех полей, по которым поиск и фильтрация часто производятся)?
Или хранение JSON и манипуляции с ним - это очень маленькая часть большого проекта, которому в остальной части требуется именно реляционная СУБД?
Ну, можете посмотреть и другие примеры других авторов на том же сайте - Мараховский там там не один такой.
Но кое в чём вы всё-таки были правы: журналисту заплатит тот, кто заинтересован. Не правы вы были в другом: в том, что читатели в принципе не являются теми кто платит, платежеспособной аудиторией.
PS Лично мне платная подписка по своему принциипу нравится больше, чем нынешняя модель финансирования публикаций через рекламу. Но чисто конкретных своих денег мне, конечно, жалко.
Таки платят. Я же вам не только общие слова сказал, но и пример привёл.
Журналисту могут заплатить и читатели, через сервис платных подписок, типа Спонсор, Бусти и т.п.
И ведь платят, что характерно! Вон, есть такой журналист Мараховский, он на Спонсоре сейчас пишет. Денег с этого немало получает (можете посмотреть - там статистика открытая), и при этом доволен, как слон (постоянно об этом упоминает), что деньги есть, а начальства нет.
Другой вот вопрос - как обычному журналисту свое имя раскрутить, чтобы стать хорошим журналистом, на которого подписываются?
Пардон, что там догонять-то?
Вы в курсе, что текущие функциональные уровни домена и леса AD DS для новейшей на сечас версии Windows Server 2022 - то, что определяет возможности AD DS как распределенной базы данных учетных записей - это уровни Windows Server 2016. Что касается клиентов, то они в большинстве случаев нечуствительны даже к таким изменениям этих самых функциональных уровней. То есть, спецификация продукта под названием Active Directory Domain Services не меняется уже почти 8 лет. Неужели за это время нельзя было (при нормальной работе) проапгрейдить роль догоняющих на роль догнавших и на это успокоившихся?
Ну, и прошу вас прояснить вопросы, которые у меня возникли к авторам обзора другой альтернативной службы каталога и централизованной аутентификации (ссылка), потому что упомянутые там возможности вашего продукта мне из этого обзора непонятны
PS Особенно интересует первый пункт: возможность изменения содержимого каталога параллельно на нескольких контроллерах домена с репликацией этих изменений на другие контроллеры и разрешением конфликтов при репликации. Потому что в те времна, когда я смотрел возможности Netscape Directory Server, этой возможности в нем не было.
Не совсем так. Я изучал этот вопрос где-то лет двадцать назад. И тогда считалось, что для описания "пожеланий заказчика" - точнее, предметной области бизнеса, функционирования предприятия и т.п. - нужно делать описания не на общечеловеческом языке, а с помощью специальных средств, таких как диаграммы САДТ (IDEF0) для функционального описания, диаграммы "сущность-связь"(IDEF1) для описания данных предприятия и т.п. Был, как минимум, один целый набор методологий (IDEF) для разработки таких описаний.
Изучал я по книгам и статьям в журналах, естественно: в фирмочке, где я тогда работал, таких сложностей не требовалось. Хотя кое-что из этого инструментария использовал - к примеру автоматическую генерацию схемы БД по методологии "сущность-связь" программой ERWin
Как с этим в нынешней реальности - не знаю. Но, судя по таким вот статьям - не очень хорошо, снизить сложность разработки и требований к квалификации программистов, непосредственно пишущих код, путем отвязывания непосредственно разработчиков от неточностей и неясностей предметной области, выяснение котторых - задача аналитиков, не получилось.
А как в этой МОС ЕС было с большими и маленькими буквами - в именах файлов и пр.? Ведь в во всех сортах *nix они всегда отличались, и это было важно, а вот на ЕС-7927 с руссифицированным под ДКОИ знакогенератором - совсем нет (отличались они на польских Mera, которые тоже были формально ЕС-7927, но в них не было русского шрифта, зато были маленькие латинские буквы).
Я это не просто так спрашиваю: это была та причина, по котрой в том ВЦ, где я тогда болтался (считал свою и физику и потихоньку хакерствовал) какая-то такая Unix-подобная система (по-моему - из Курчатника, т.е. ДЕМОС) была зарублена, хотя во всем остальном она никому не мешала, потому что там в качестве основной ОС IBM VM/SP был (это - гипервизор), а под ним что угодно можно было запускать (например, тот же VM/SP - я так развлекался, если чо).
Тут неприятности могут случиться ещё до кэша: чтение значения переменной _random и проверка его на null уже были сделаны чуть ранее, и компилятор/JIT может решить, что второй раз проделывать ту же работу незачем.
Тут вопрос, когда оно будет перенесено и увидит ли вовремя это новое значение поток, пытающийся выполнить инициализацию параллельно на другом процессоре? Без Volatile таких гарантий, в общем случае, нет, а модели памяти процессоров и синхронизации кэшей - они в этом плане различаются. Да ещё и в будущем могут различия в неблагоприятную сторону появиться: синхронизация кэшей - операция дорогая, и у разработчиков железа всегда есть соблазн попытаться на этом сэкономить. Так что IMHO, как это часто бывает при разработке в условиях параллельности, лучше заранее соломку подстелить в виде гарантий наличия барьеров, чем отлавливать потом плавующую ошибку синхронизации.
Первый комментарий в этой ветке (не мой) содержит цитату.
Но ведь вы-то в своих рассуждениях привязываете.
Я не буду тут вдаваться в подробности, как возникает стоимость, и как сочетаются между собой ваши приверженности одновременно к трудовой теории стоимости (основе экономических воззрений марксистов) и к неолиберализму. Хотя мне тут есть что сказать - начиная с опровержений марксизма со стороны маржиналистов.
Мне сейчас важно, что вы таки имели в виду меновую стоимость , а не потребительную (т.е. само благо). Тогда мое возражение - а оно относится именно к меновой стоимости, чем бы конкретно она не определялась - остается в силе: оказывается, что меновая стоимость в течение времени не сохраняется. И это - принципиальное следствие технического прогресса (который вы, надеюсь, не отрицаете).
Ну и как в таком случае может быть справедливым тезис, на котором вы основыветесь - что деньги могут иметь неизменную покупательную способность?
Ну, про стоимость много разных вопросов задать можно. Первый - в чем ее мерять? В конкретном благе (а тогда сразу вопрос - как сопоставлять разные блага?)? В необходимых (иначе - неустранимых) издержках на производство данного конкретного блага (типа затрат труда в трудовой теории стоимости)?
Вопрос не просто так, потому что одно и то же благо с течением времени может потребовать, ну, совершенно разных издержек на свое производство: технический прогресс идёт, однако. Один из наиболее ярких примеров - алюминий: чушка алюминия где-нибудь в 1880-м году требовала гораздо больших затрат на ее создание, чем четверть века спустя - после изобретения получения электролизом глинозема в криолите и появления дешевых источников электроэнергии (это - ещё одна цепочка изобретений и усовершенствований).
Так что, не знаю, интуитивно оно, или нет, но, в общем случае - неверно.
Если хорошо подумать, то в данном случае, когда изменение поля возможно только в одном направлении, с null на уже созданный объект (если я правильно понял это из фрагментов кода в статье) - совершенно необязательно. Если содержимое поля, сейчас или когда-то ранее, уже оказалось непустым значение, то, при условии правильно расставленных барьеров внутри lock-блока, другому значению там взяться будет неоткуда. А оптимизация благодаря этому может оказаться существенной.
Но вот внутри lock-блока все должно быть с надлежащими барьерами - и чтение, и запись, - примерно так:
Но, возможно, лучше действительно не думать, а использовать стандартные средства библиотеки языка для отложенной инициализации. А если таки понадобится оптимизация - подумать о ней потом, благо поле - частное, и на интерфейс библиотеки оно не повлияет никак.
PS А ещё я не люблю слово "анти-паттерн". Потому что применяющие его зачастую стремятся просто запретить использовать объявленное "анти-паттерном" решение, а не задуматься, применимо ли оно в конкретной задаче.
Ваше суждение излишне безапелляционно (IMHO)
По-моему, вы не слишком осведомлены в истории появления ООП. "На заре" - это лет сорок назад, по крайней мере первый язык ООП- Smalltalk - был упомянут ещё в статье про Настоящих Программистов (тех самых, которые не используют Паскаль), вышедшей уже более 40 лет тому назад.
Хранить-то можно что угодно - вопрос как с этим работать.
Например, что делать, когда потребуется поиск/фильтрация/сортировка по полям? Ответ известен - создавать индекс, но индексировать поля однородных записей в таблицах значительно проще и эффективнее, чем поля объектов произвольной, возможно - сложной, структуры.
Или - как хранить объекты, являющииеся полями других объектов? Если - как части объектов, в которые они входят, то получается денормализованная структура, со всем присущими ей аномалиями - обновления и т.д. Ели как ссылки на вложенные объекты - то как поддерживать эти ссылки. И т.д.
Если для вашего проекта объектная БД подходит - используйте. Но это решение - тоже не универсальное. Как и противоположное - не использовать в сколь-нибудь сложных проектах объекты вообще, даже в коде: видел и такое в комментариях ув. @SpiderEkbк недавней статье, вызванных его опытом работы с высокнагруженным ядром банковской системы крупного банка. Даже в коде, в памяти - а уж использовать в таких проектахобъектных хранилищ данных, и тянуть, фигурально выражаясь, когда нужен только банан, ещё и обезьяну, которая его держит, и джунгли, где обезьяна живет - это вообще за всякие рамки входит.
Короче мое мнение: всякое решение имеет ограниченную область применения. И подобрать решение для конкретной задачи - это уже отдельное умение. Использовать для этого такие грубые шаблоны, как вы тут пишете - это неуместно.
Ну да, sqlite — это хорошее современное воплощение хорошей старой идеи. Самой идее-то — лет 30, как минимум. В первой половине 90-х на ПК были широко распространены встраиваемые прямо в приложение файловые базы данных на реляционной основе (то есть, сделанные из таблиц и индексов) — dBase+Clipper, Paradox и пр… И NoSQL — с сетевой моделью данных, сейчас бы ее отнесли, наверное, к графовым — БД тоже была: dbVista, переименованная впоследствии в Raima Database Manager. И библиотеки для работы с файлами формата таких БД тоже были: CodeBase — для работы из C с форматом dBase и Clipper (этой сам активно пользовался), потом — IDAPI, она же — BDE (Borland Database Engine), которая могла работать и с файловыми форматами БД (Paradox и dbBase), и с SQL-серверами. С SQL, правда, было бедно: на ПК для него памяти было откровенно мало (особенно в DOS), потому все больше пользовались навигационным доступом (это — к отдельным таблицам, по одной записи, можно искать по индексу), но где-то во второй половине 90-х SQL стал вполне поддерживаться: в частности (из того, чем я пользовался сам), прикрутили SQL к BDE в качестве встроенного в него самого.
Ну, и сейчас SQLite — не единственная встроенная БД. Есть, как минимум, Embedded MS SQL — он используется для разработки, но вот разрешает ли MS его использовать для программ на ПК — это я не в курсе.
PS А ещё где-то мимо меня прошел MS Access: к нему тоже можно было обращаться из программ через ODBC или OLEDB/ADO, но с ним я никогда в таком режиме не работал.
Нет. Для самой начальной загрузки использовался интерфейс работы с диском из BIOS (Int 13, для этого с самом контроллере диска было ПЗУ для расширения BIOS), через него загружался указанный в конфигурации (в реестре с типом запуска start= boot) драйвер ядра NT и дальше шла работа с диском через этот драйвер. Реестр просматривался загрузчиком тоже через BIOS, а путь к установленной Windows NT был прописан в файле boot.ini в совершенно нестандартном для мира ПК формате ARC.
При установке установщик пробовал все известные ему драйверы диска, если же ни один не подходил — требовал дискету (именно дискету!) с нужным драйвером.
Впрочем, были способы встроить такой драйвер в дистрибутив (например — программой nLite)
Эта схема загрузки использовалась до Win2K3 Srv включительно, а современная схема появилась только в Vista
Вроде как, между уровнем БД и уровнем бизнес-логики часто бывает уровень абстрактного хранилища объектов: хранилище отображает объекты, с которыми работает бизнес-логика, на операции уровня БД. И ORM как раз этим и занимается.
Так что сдвигать задачу на уровень БД — ее схемы и операций с ней — в общем случае совсем не обязательно. При низких требованиях к производительности можно обойтись ORM и тем самым сэкономить на персонале (а бизнес экономить любит, да), которому не нужно уметь работать на уровне БД: знать SQL и, тем более, язык хранимых процедур конкретной БД, и, тем более, читать планы выполнения запросов, думать о необходимости индексов, избегать излишних блокировок и заниматься прочими обязанностями DBA.
Бизнес-логика же при наличии такого абстрактного хранилища в виде ORM будет работать с объектами вполне статических типов (не скажу за все ORM, но конкретно EF это более чем позволяет: это его основной режим работы).
Все это замечательно здравствует, пока не возникают нагрузки, для которых требуется оптимизация, хоть какая-то. Но это уже другая история.
А если вспомнить исходный комментарий ветки от ImagineTables то, безотносительно к GraphQL, схема данных желательна (ибо дисциплинирует), но, накрайняк, без нее можно обойтись (например, так обстоит дело в мире XML). Проверять же запрос на правильность формулирования можно и при его приеме на севере. Правда тогда есть риск возникновения разных представлений о схеме данных у разных людей — и вот тут-то схема и проверка по ней станет настоятельно необходимой.
Мы тут, вроде как, GraphQL исключительно обсуждаем, не так ли?
А если не просто, а через ORM?
Я вот смотрю на примеры возвращаемых результатов через GraphQL и у меня перед глазами прямо встают типы DTO для Entity Framework (это ORM для C#, если кто вдруг не в курсе). Остается только прикрутить библиотеку преобразования запроса c языка GraphQL в LINQ — и можно работать с реляционной БД, не сильно при этом задумываясь.
Это вы про C# или вообще?
Если про C# то покажите мне способ получиь гарантию от компилятора, что делегат, который мне могут передать в мою функцию, не может не быть чистой функцией. Я такого способа, например, не знаю. А в отсутствии этой гарантии от компилятора функциональное программирование превращается в «функциональщину», которая ничего такого прекрасного не позволит.