Здравствуйте, kov_serg, Вы писали:

_>

Будущий язык будет обеспечивать в процессе работы модули безопасности и контролируемый доступ к данным.

_>Поддержка сорм из каропки это замечательно.

Справедливости ради, удобный язык для удалённого доступа к данным напрашивается уже слишком давно.

Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.

Здравствуйте, vdimas, Вы писали:

V>Потому что SQL безбожно устарел и вообще

Это ты малость от жизни отстал. Несколько лет назад движуха была с криками "No SQL", потом стали тише говорить "Not only SQL", а сейчас все чаще слышно тихое "Not yet SQL"

V>в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.

Это только если нагрузка незначительная.

Здравствуйте, vdimas, Вы писали:

V>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.

Люди которые это делают всё-равно некомпетентны.

Здравствуйте, MTD, Вы писали:

V>>Потому что SQL безбожно устарел и вообще
MTD>Это ты малость от жизни отстал. Несколько лет назад движуха была с криками "No SQL"

Я эти крики слышал.


MTD>потом стали тише говорить "Not only SQL", а сейчас все чаще слышно тихое "Not yet SQL"

Это потому что нет подходящего языка.
Вернее, они есть, но не вышли за рамки "вещи в себе" некоторых NoSQL баз данных.


V>>в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.
MTD>Это только если нагрузка незначительная.

Ты имеешь ввиду ситуацию, когда SQL вообще представляется сущностю третьего рода, от бишь вовсе чужеродной хренью в программе, типа склеиваемых вручную строк? ))

Здравствуйте, Nikе, Вы писали:

V>>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.
N>Люди которые это делают всё-равно некомпетентны.

Откуда инфа?

Здравствуйте, vdimas, Вы писали:

V>>>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.
N>>Люди которые это делают всё-равно некомпетентны.

V>Откуда инфа?

Работал с ними.

Здравствуйте, vdimas, Вы писали:

V>>>в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.
MTD>>Это только если нагрузка незначительная.

V>Ты имеешь ввиду ситуацию, когда SQL вообще представляется сущностю третьего рода, от бишь вовсе чужеродной хренью в программе, типа склеиваемых вручную строк? ))

Хренью тоже может быть — это уж как напишешь (пишут, ксати не только в программе, гугли хранимые процедуры). Но всякие ORM помимо проблем с производительностью, которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе. Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах. Почему это неправильно? Потому, что бизнес-логика изменчива и может меняться, а данные в базе — это данность, если Вася заплатил в 2010 году 100 рублей Пете, то это уже произошло и не изменится.

Здравствуйте, MTD, Вы писали:

V>>Ты имеешь ввиду ситуацию, когда SQL вообще представляется сущностю третьего рода, от бишь вовсе чужеродной хренью в программе, типа склеиваемых вручную строк? ))
MTD>Хренью тоже может быть — это уж как напишешь (пишут, ксати не только в программе, гугли хранимые процедуры).

С какой целью гуглить хранимые процедуры?
И как это избавляет от строкового "{? = call proc_name(42, 43)}" или от "exec @ret=proc_name @param1=42, @param2=43"?

Даже если ты используешь некий "высокоуровневый объект" для вызова удалённых хранимок, это ничем не отличается от хелпера для формирования указанной строки.


MTD>Но всякие ORM помимо проблем с производительностью

Вот! Верно.
Потому что сущность второго рода.
Оптимизация компилятору недоступна, часто "компиляция" выполняется в рантайм.
Т.е. маппер генерируется по-месту, прежде чем начать что-то маппить.
А простые ORM, типа LinQ, и вовсе работают в режиме интерпретатора метаинформации для каждого поля каждой строчки, например, огромного рекордсета.


MTD>которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе.

Это уже вопросы прикладного плана.
Где-то кеши уместны, где-то нет.
Но в базе должен быть эффективный и безопасный (в плане типов) инструмент.
А такого нет.
Т.е. вот отправляется запрос на сервер и уже оба ендпоинта должны заранее знать тип возвращаемого результата, а не гнать каждый раз метаинформацию и интерпретировать её на каждой из сторон.


MTD>Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах.

Это тоже как раз нормально.
Данные есть данные.
Тут идёт разговор об удобном и эффективном оперировании данными.


MTD>Почему это неправильно? Потому, что бизнес-логика изменчива и может меняться, а данные в базе — это данность, если Вася заплатил в 2010 году 100 рублей Пете, то это уже произошло и не изменится.

Сам с собой споришь. ))
Так это "неправильно" или такова природа вещей?
Меня может тоже бесит, что котангес 𝜋 никак не может определиться — он плюс бесконечность или, всё-таки, минус бесконечность.
Но я ж смирился и живу с этим как-то...

Здравствуйте, vdimas, Вы писали:

V>С какой целью гуглить хранимые процедуры?

С целью расширения кругозора.

V>И как это избавляет от строкового "{? = call proc_name(42, 43)}" или от "exec @ret=proc_name @param1=42, @param2=43"?

А должно избавлять?

V>Даже если ты используешь некий "высокоуровневый объект" для вызова удалённых хранимок, это ничем не отличается от хелпера для формирования указанной строки.

И что? В чем проблема?

MTD>>Но всякие ORM помимо проблем с производительностью

V>Вот! Верно.

Я рад.

MTD>>которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе.

V>Где-то кеши уместны, где-то нет.

Кеши уместны везде, другое дело, что их бывает недостаточно, а еще вместе с ними приходит и сложность.

V>Но в базе должен быть эффективный и безопасный (в плане типов) инструмент.

Да.

V>А такого нет.

Да.

V>Т.е. вот отправляется запрос на сервер и уже оба ендпоинта должны заранее знать тип возвращаемого результата

Естественно.

V>а не гнать каждый раз метаинформацию и интерпретировать её на каждой из сторон.

Зачем нужна метаинформация?

MTD>>Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах.

V>Это тоже как раз нормально.

Нет. Почему я уже объяснил.

V>Тут идёт разговор об удобном и эффективном оперировании данными.

И? Твои тезисы?

V>Сам с собой споришь. ))

Не спорю, а объясняю, но видимо зря.

V>Но я ж смирился и живу с этим как-то...

Аминь.

Здравствуйте, MTD, Вы писали:

V>>С какой целью гуглить хранимые процедуры?
MTD>С целью расширения кругозора.

Будь конкретнее, плиз, в какую сторону надо расширять мой кругозор и чем он хуже твоего?


V>>И как это избавляет от строкового "{? = call proc_name(42, 43)}" или от "exec @ret=proc_name @param1=42, @param2=43"?
MTD>А должно избавлять?

Разумеется.
На серверной стороне тоже.

Де-факто вся индустрия пользуется языком чуть ли не времён Фортрана с примерно таким же качеством его дизайна. Т.е. для своего времени язык был замечателен, требовал минимум ресурсов на его компилятор/интерпретатор, но морально устарел уже к концу 90-х.


V>>Даже если ты используешь некий "высокоуровневый объект" для вызова удалённых хранимок, это ничем не отличается от хелпера для формирования указанной строки.
MTD>И что? В чем проблема?

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


MTD>>>которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе.
V>>Где-то кеши уместны, где-то нет.
MTD>Кеши уместны везде, другое дело, что их бывает недостаточно, а еще вместе с ними приходит и сложность.

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


V>>Т.е. вот отправляется запрос на сервер и уже оба ендпоинта должны заранее знать тип возвращаемого результата
MTD>Естественно.
V>>а не гнать каждый раз метаинформацию и интерпретировать её на каждой из сторон.
MTD>Зачем нужна метаинформация?

Зачем она нужна прямо сейчас? ))
Потому что имеет место динамическая типизация, это ж классика жанра.


MTD>>>Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах.
V>>Это тоже как раз нормально.
MTD>Нет. Почему я уже объяснил.

Не объяснил.
Вопрос сам по себе не простой, твоё "объяснение" не потянуло даже на заголовок краткого обзора этого вопроса.


V>>Тут идёт разговор об удобном и эффективном оперировании данными.
MTD>И? Твои тезисы?

Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.
И отсюда иметь возможность по-настоящему заняться оптимизацией, типа как в современном С++.


MTD>Не спорю, а объясняю, но видимо зря.

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

Здравствуйте, vdimas, Вы писали:

MTD>>С целью расширения кругозора.

V>Будь конкретнее, плиз, в какую сторону надо расширять мой кругозор и чем он хуже твоего?

Во все стороны, только очень тупой глупый считает, что ему кругозор расширять не надо. Мне естественно тоже расширять надо, так как я знаю, что много не знаю.

V>>>И как это избавляет от строкового "{? = call proc_name(42, 43)}" или от "exec @ret=proc_name @param1=42, @param2=43"?
MTD>>А должно избавлять?

V>Разумеется.
V>На серверной стороне тоже.

Как?

V>Де-факто вся индустрия пользуется языком чуть ли не времён Фортрана с примерно таким же качеством его дизайна. Т.е. для своего времени язык был замечателен, требовал минимум ресурсов на его компилятор/интерпретатор, но морально устарел уже к концу 90-х.

Критерии в студию.

V>>>Даже если ты используешь некий "высокоуровневый объект" для вызова удалённых хранимок, это ничем не отличается от хелпера для формирования указанной строки.
MTD>>И что? В чем проблема?

V>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы.

Опять бла-бла-бла. Конкретней.

MTD>>Кеши уместны везде, другое дело, что их бывает недостаточно, а еще вместе с ними приходит и сложность.

V>Это тебя опять тянет на прикладной уровень, а он зависит от конкетных сценариев, т.е. обобщать здесь бессмысленно.

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

V>>>Т.е. вот отправляется запрос на сервер и уже оба ендпоинта должны заранее знать тип возвращаемого результата
MTD>>Естественно.
V>>>а не гнать каждый раз метаинформацию и интерпретировать её на каждой из сторон.
MTD>>Зачем нужна метаинформация?

V>Зачем она нужна прямо сейчас? ))
V>Потому что имеет место динамическая типизация, это ж классика жанра.

Зачем нужна метаинформация?

V>Не объяснил.

Объяснил. Подумай немного, если что-то непонятно задай уточняющий вопрос.

V>>>Тут идёт разговор об удобном и эффективном оперировании данными.
MTD>>И? Твои тезисы?

V>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.

Как?

V>И отсюда иметь возможность по-настоящему заняться оптимизацией, типа как в современном С++.

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

V>Путать прикладные сценарии со способами их реализации... ну я просто сижу и пытаюсь не улыбаться.

Ну так не путай.

Здравствуйте, MTD, Вы писали:

MTD>>>С целью расширения кругозора.
V>>Будь конкретнее, плиз, в какую сторону надо расширять мой кругозор и чем он хуже твоего?
MTD>Во все стороны, только очень тупой глупый считает, что ему кругозор расширять не надо.

Вопрос стоял не так, вопрос был — почему ты мне это посоветовал в этом обсуждении.
Что было не так?


V>>На серверной стороне тоже.
MTD>Как?

Через типизированный язык.
В базе-то сидит реляционная алгебра, а она строго типизирована.
Отношения — они строго типизированы.
Соответственно, любой кортеж — тоже строго типизированный.
С учётом принятого в БД способа именнованного (а не позиционного) обращения к полям кортежей, можно напрямую использовать наработки из мейнстримовых языков, где в них описываются типизированные пользовательские структуры данных.

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


V>>Де-факто вся индустрия пользуется языком чуть ли не времён Фортрана с примерно таким же качеством его дизайна. Т.е. для своего времени язык был замечателен, требовал минимум ресурсов на его компилятор/интерпретатор, но морально устарел уже к концу 90-х.
MTD>Критерии в студию.

1. Типобезопасность, помощь со стороны компилятора;
2. Мощные, выразительные ср-ва языка;
3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;

В итоге — готовность работать с современными гигабитными сетками.
Мейнстримовые БД с такими сетками работать де-факто не готовы.
Сам я последние много лет работаю именно с протоколами удалённого доступа к данным.
Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их.
Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет".

Всё не так.
Причём, совершенно не так уже относительно давно.

Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой.


V>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы.
MTD>Опять бла-бла-бла. Конкретней.

Это было более чем конкретно.


V>>Это тебя опять тянет на прикладной уровень, а он зависит от конкетных сценариев, т.е. обобщать здесь бессмысленно.
MTD>Меня никуда не тянет, ты решил поговорить ни о чем, я тебе помогаю подбрасывая тем.

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


V>>Потому что имеет место динамическая типизация, это ж классика жанра.
MTD>Зачем нужна метаинформация?

Зачем нужна метаинформация в случае динамической типизации я объяснять не буду.
Это хорошо объясняется на всех углах и без меня.


V>>Не объяснил.
MTD>Объяснил. Подумай немного, если что-то непонятно задай уточняющий вопрос.

Тут надо было объяснить — о какой именно задаче идёт речь.
Но этого так и не прозвучало, соответственно, вопросы задавать не по чему.
Это ведь тоже классика жанра — уметь делать постановку задачи, т.е. формулировать проблематику.
Ты же высказался о проблематике решения, а не задачи.
Поэтому, низачОт. ))


V>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.
MTD>Как?

Как в С++, Java/Net, Swift и т.д.


V>>И отсюда иметь возможность по-настоящему заняться оптимизацией, типа как в современном С++.
MTD>Вот есть файл, в нем лежат байты, на уровне байт нет никакой информации о высокоуровневых сущностях и логике.

Форматы хранения даных в различных БД открыты, спор ни о чём.
Сами данные хранятся как строго-типизированные.
У меня в объекте HashTable<ID, Record> или в Aray<Record> тоже нет никакой информации о "высокоуровневых сущностях и логике", но это не мешает компилятору оптимизировать все действия с такой структурой данных.


MTD>Или на примере сокета — сериализовали сущность в байты и кинули в сокет, на другой стороне достали и десиарилизовали, для этого оба участника должны знать информацию о типе, а по дороге это просто байты. Твои предложения?

Выделил жирным.
Ведь SSL как-то работает, верно?
Он обменивается строго-типизированными своими сообщениями.
Т.е. оба ендпоинта оперируют одними и теми же типами.
Т.е. опять ты проблематику не сформулировал.

Здравствуйте, vdimas, Вы писали:

V>Меня может тоже бесит, что котангес 𝜋 никак не может определиться — он плюс бесконечность или, всё-таки, минус бесконечность.

Он просто не существует. Делить на ноль нельзя.

Здравствуйте, Nikе, Вы писали:

N>Работал с ними.

А это, часом, не Ростелеком со своими дочками (например, Рестрим) делает?

Здравствуйте, MTD, Вы писали:


MTD>Но всякие ORM помимо проблем с производительностью, которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе.

Много раз слышал от разных людей. Для начала пара слов про производительность. С производительностью проблема возникает от того, что ORM тупо не поддерживают плюхи конкретных СУБД. И приходится использовать нативный sql, чтобы их заюзать. С использованием нативного sql в некоторых местах в ORM проблем нет. В пределе, конечно, может быть надо будет отказаться от ORM совсем, но дойти до этого предела непросто, так как ORM упрощает 80% типовых операций и делает это хорошо. Других проблем с производительностью, специфичных только для ORM, у ORM нет.

MTD>Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах.

Ну, не прибивай бизнес-логику к полям в таблицах. ORM не предполагает, что бы будешь это делать. По идее ORM занимается построением типовых запросов и отображением таблиц в объекты, в которых логики быть РЕШИТЕЛЬНО НЕ ДОЛЖНО. Прямо вот так, капсом . Объекты этим, соответственно, поведением не обладают и не инкапсулируют состояние и, следовательно, объектами в понимании ООП не являются, а являются структурами.

MTD>Почему это неправильно? Потому, что бизнес-логика изменчива и может меняться, а данные в базе — это данность, если Вася заплатил в 2010 году 100 рублей Пете, то это уже произошло и не изменится.

Бизнес логика, да, может меняться независимо от БД, поэтому, повторюсь нельзя помещать логику в объекты, отображением которых в БД занимается ORM. А лучше вообще не показывать эти объекты коду, который занимается бизнес-логикой. Данные в базе это данность, но вот структура БД может и будет меняться так же, как и бизнес логика. И очень удобно, когда можно менять одно независимо от другого.

Здравствуйте, vdimas, Вы писали:

V>1. Типобезопасность, помощь со стороны компилятора;
V>2. Мощные, выразительные ср-ва языка;
V>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;

LINQ не подходит?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, vdimas, Вы писали:
IT>LINQ не подходит?

Это очень опасный вопрос. Вам vdimas сейчас накатает простыню про преимущества C++

Здравствуйте, IT, Вы писали:

V>>1. Типобезопасность, помощь со стороны компилятора;
V>>2. Мощные, выразительные ср-ва языка;
V>>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;
IT>LINQ не подходит?

Внешний синтаксис вполне.
Промежуточное представление — мрак.
Дерево экспрешшенов в рантайме — хана всему.

Здравствуйте, vdimas, Вы писали:

V>Внешний синтаксис вполне.
V>Промежуточное представление — мрак.
V>Дерево экспрешшенов в рантайме — хана всему.

Второе и треье вроде одно и то же. Или мы по разному понимаем что такое LINQ?

Здравствуйте, vdimas, Вы писали:

V>>>На серверной стороне тоже.
MTD>>Как?

V>Через типизированный язык.
V>В базе-то сидит реляционная алгебра, а она строго типизирована.
V>Отношения — они строго типизированы.

Я не понимаю, ты же сам пишешь, что на сервере уже все типизировано.

V>Это приведёт к еще одной разновидности оптимизации — повторному использованию кода, бо "тип" может быть отделён от "экземпляра", что тоже кардинально развяжет руки разработчикам. Потому что "мыслить категориями доменов" уместно далеко не во всех сценариях вокруг хранения данных. Я бы даже предположил — в подавляющем меньшинстве их.

Пример?

V>>>Де-факто вся индустрия пользуется языком чуть ли не времён Фортрана с примерно таким же качеством его дизайна.

V>1. Типобезопасность, помощь со стороны компилятора;
V>2. Мощные, выразительные ср-ва языка;
V>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;

А чего из перечисленного нет в Фортране?

V>В итоге — готовность работать с современными гигабитными сетками.
V>Мейнстримовые БД с такими сетками работать де-факто не готовы.

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

V>Сам я последние много лет работаю именно с протоколами удалённого доступа к данным.
V>Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их.

Это булшит. Удаленный доступ может быть хоть голубиной почтой, естественно микросекунд там не будет.

V>Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет".

Я такое говорил? Нет? А к чему ты это написал?

V>Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой.

Это полная чушь или уточни, что ты подразумеваешь под "интерфейсный".

V>>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы.
MTD>>Опять бла-бла-бла. Конкретней.

V>Это было более чем конкретно.

Нет — это бла-бла-бла.

V>Я говорил о языке (или языках, не суть), предназначенном для обработки данных и инфраструктуре вокруг этого языка.

Ну вот и говори про него, пока ничего конкретного не сказал.

V>>>Потому что имеет место динамическая типизация, это ж классика жанра.
MTD>>Зачем нужна метаинформация?

V>Зачем нужна метаинформация в случае динамической типизации я объяснять не буду.
V>Это хорошо объясняется на всех углах и без меня.

А при чем тут языки с динамической типизацией?

V>>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.
MTD>>Как?

V>Как в С++, Java/Net, Swift и т.д.

Мы про БД говорим. Как?

V>>>И отсюда иметь возможность по-настоящему заняться оптимизацией, типа как в современном С++.
MTD>>Вот есть файл, в нем лежат байты, на уровне байт нет никакой информации о высокоуровневых сущностях и логике.

V>Форматы хранения даных в различных БД открыты, спор ни о чём.

Никто не спорит, тебе просто показали, что байты ни про какую типизацию не в курсе.

V>Сами данные хранятся как строго-типизированные.
V>У меня в объекте HashTable<ID, Record> или в Aray<Record> тоже нет никакой информации о "высокоуровневых сущностях и логике", но это не мешает компилятору оптимизировать все действия с такой структурой данных.

Так и в БД все типизировано и не поверишь — там тоже есть оптимизатор. Твои идеи, или просто потрындеть?

MTD>>Или на примере сокета — сериализовали сущность в байты и кинули в сокет, на другой стороне достали и десиарилизовали, для этого оба участника должны знать информацию о типе, а по дороге это просто байты. Твои предложения?

V>Выделил жирным.
V>Ведь SSL как-то работает, верно?

А он то причем?

V>Он обменивается строго-типизированными своими сообщениями.

А внутри байты. Файловая система тоже свою строго-типизированную информацию о файлах хранит.

V>Т.е. оба ендпоинта оперируют одними и теми же типами.

Отлично, речь то о чем?

V>Т.е. опять ты проблематику не сформулировал.

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