S>Самое забавное, но я в свое время думал именно в сторону туристического бизнеса в плане обоснования необходимости применять ООСУБД.
S>Собственно, то, что ты пока что рассказал, ничего сложного не представляет. Ну да, довольно таки разветвленная структура таблиц. Нудно, но не сложно. Просто сидишь и методично выписываешь все атрибуты...
S>Сложность — в выполнении запроса "выведи мне все предложения, удовлетворяющие вот-тому то". Ну типа "семья из двух человек с ребенком хочет отдохнуть на побережье греции". И сортировать надо по стоимости. С учетом всех этих безумных pricing rules. Даже расчет стоимости авиаперелета плохо делается автоматом. У нас так до сих пор вручную все делают. И бывают потом конфликты с авиакомпанией, когда оператор выдает билет по несуществующему тарифу.

О! Это я и хотел сказать, но косноязычие подвело

Orbitz:

6. If you want to do a simple round-trip from BOS to LAX in two weeks, coming back in three, willing to entertain a 24 hour departure window for both parts, then limiting to "reasonable" routes (at most 3 flights and at most 10 hours or so) you have about 5,000 ways to get there and 5,000 ways to get back. Listing them is a mostly trivial graph-search (there are a few minor complications, but not many), that anybody could do in a fraction of a second.

7. The real challenge is that a single fixed itinerary (a fixed set of flights from BOS to LAX and a fixed set back) with only two flights in each direction may have more than 10,000 possible combinations of applicable "fares", each fare with complex restrictions that must be checked against the flights and the other fares. That means that the search space for this simple trip is of the order 5000 x 5000 x 10000, and a naive program would need to do a _lot_ of computation just to validate each of these possibilities. Suitably formalized, its not even clear that the problem of finding the cheapest flight is NP-complete

Кстати, наблюдал собственными глазами в ticket отделе следующую ситуацию. Какой-то мужик хотел полететь из Стамбула в Петербург обязательно через Осло с остановкой в Вене Оператор пыталась заставить систему (Amadeus) выдать остановку в Осло меньше, чем 24 часа Не помню, чем все это закончилось. По-моему, 8-часовой остановкой в Вене.

Если в следующий раз при поездке в Турцию вас поселят не в том отеле, не удивляйтесь

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

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

D>>API Raima dbVista действительно чревато многочисленными граблями. Но это отнюдь не является следствием сетевой модели. Это скорее из-за древности данной конкретной СУБД.

L>Допустим даже это.. как насчет привести в пример какую-нибудь классную реализацию сетевой модели? )

IMS (Information Management System) — наиболее старая СУБД фирмы IBM. Она поддерживает иерархическую модель данных... (не очень классная, но куда "древней" dbVista)

СУБД ADABAS/NATURAL — это мультимодельная система, позволяющая строить иерархические, сетевые и SQL — реляционные базы данных, а также сложные текстовые или географические системы...

здесь


Еще по ADABAS:
здесь
здесь

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

M>Объектно-ориентированная, но сам движок сделан на реляционой =)

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

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

M>Точно, мумпс — это иерархическая субд (такие были до реляционных)(одна из проблем — это для того, чтобы по порядку выбрать записи "таблицы", нужно было подниматься по ссылке к родителю, выбирать следующую ссылку, и по ней опускаться обратно). к ней прикручены интерфейсы sql и ооп.

А ты не путашь многомерные и иерерхические?

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

M>> С объектами же программисты привыкли делать всё, что им заблагорассудится.
M>Угу, а знаешь почему? Потому что объект != данные. Объект — это поведение, данные же остаются неизменными, отсюда и возникает эта невиданная простота и легкость. Сегодня мы данные трактуем так — у нас один объект, завтра надо по другому — не вопрос, объект поменяли, данные остались. А как только мы пытаемся работать с данными как с объектами, то тут же вся гибкость идет лесом и на поверку оказывается, что реляционное представление данных, на данный момент, по гибкости еще никому превзойти не удалось, не смотря на то что из соображений производительности приходится в некоторой степени завязывать струтуру БД на семантику данных.
Честно говоря не вижу принципиальных препятствий для хранения объектов в БД в виде подобном тому, в каком они хранятся в оперативной памяти. Есть класс с описанием и методами, есть много его экземпляров с полями, со ссылками на другие объекты. В результате ВСЯ бизнес-логика сделана в методах этих классов, через них и работают пользователи БД.
Почему нельзя так?

M>> Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL).
M>Нет, в коде это еще не идеал. Заказчик должен кубики и стрелочки на экране передвигать.
Конечно! Заказчик рисует стрелочки и кубики, только в такой нотации, которая однозначно описывает модель на языке программиста. А программист на оновании этих рисунков вносит изменения в систему. Время, когда схема, нарисованная заказчиком, будет автоматически пониматься системой (без участия программиста), думаю настанет ещё не скоро.

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

M>Честно говоря не вижу принципиальных препятствий для хранения объектов в БД в виде подобном тому, в каком они хранятся в оперативной памяти.
Видишь суслика? Хранить объекты в БД в таком же виде как в памяти пытается уже ни одно поколение разработчиков, заметного прогресса пока не наблюдается...

M> Есть класс с описанием и методами, есть много его экземпляров с полями, со ссылками на другие объекты. В результате ВСЯ бизнес-логика сделана в методах этих классов, через них и работают пользователи БД.
M>Почему нельзя так?
Очень просто. Бизнес-логика меняется, при том что данные остаются теми же. При изменении бизнес-логики, данные должны сохраниться, таким образом, в предложенной схеме, меняя объект, нам надо приложить бездну усилий, чтобы добиться неизменности и непротиворечивости данных. Реляционка же позволяет данные от логики отделить и менять одно независимо от другого с наименьшими дополнительными затратами. На практике оказывается намного дешевле потрахаться один раз при проектировании системы, чем трахаться каждый раз при изменении логики приложения и семантики данных.
Мухи и котлеты. Мухи летают, котлеты лежат на месте. Нельзя заставить котлеты летать, точнее можно, конечно, но плохо и не далеко, не надо пытаться облепить котлету мухами и думать, что она после этого полетит....

M>Конечно! Заказчик рисует стрелочки и кубики, только в такой нотации, которая однозначно описывает модель на языке программиста. А программист на оновании этих рисунков вносит изменения в систему.
Нафиг-нафиг. Во-првых я не встречал еще ни одной нотации, ктороая бы смогла однозначно описать модель да еще и на языке программиста, а во-вторых, я уж тем более не встречал ни одного заказчика четко понимающего что он хочет.
Поэтому если уж между заказчиком и системой стоит программист, то пусть общаются словами — оно существенно эффективнее.

M>Время, когда схема, нарисованная заказчиком, будет автоматически пониматься системой (без участия программиста), думаю настанет ещё не скоро.
Ну почему же... Уже в 2004 BizTalk-е была чудестная компонента (которую к слову, если я правильно помню, можно выдрать и вставить в свое приложение), которая позволяет прямо в студии, в картинках, описывать некие бизнес-правила, в частности ценообразование, и оные бизнесправила, без малейшего участия программиста вступают в силу, в указанные сроки.
Так что заказчицкое счастье в принципе возможно...

Mazay wrote:

> Честно говоря не вижу принципиальных препятствий для хранения объектов
> в БД в виде подобном тому, в каком они хранятся в оперативной памяти.
> Есть класс с описанием и методами, есть много его экземпляров с
> полями, со ссылками на другие объекты. В результате *ВСЯ*
> бизнес-логика сделана в методах этих классов, через них и работают
> пользователи БД. Почему нельзя так?

Как индексы будете строить

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

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

M>>Честно говоря не вижу принципиальных препятствий для хранения объектов в БД в виде подобном тому, в каком они хранятся в оперативной памяти.
M>Видишь суслика? Хранить объекты в БД в таком же виде как в памяти пытается уже ни одно поколение разработчиков, заметного прогресса пока не наблюдается...
Жаль.

M>Очень просто. Бизнес-логика меняется, при том что данные остаются теми же. При изменении бизнес-логики, данные должны сохраниться, таким образом, в предложенной схеме, меняя объект, нам надо приложить бездну усилий, чтобы добиться неизменности и непротиворечивости данных. Реляционка же позволяет данные от логики отделить и менять одно независимо от другого с наименьшими дополнительными затратами. На практике оказывается намного дешевле потрахаться один раз при проектировании системы, чем трахаться каждый раз при изменении логики приложения и семантики данных.
По-моему реляционка просто забивает на бизнес-логику. Делай трехзвенку и реализуй логику на чём хочешь. Программисту конечно фиолетово, ему только заработок лишний от поддержки софта (вон как 1С этот процесс на конвейер поставила). Вот только тоскливо клепать в сущности похожие обработки, запросы и т.п. Хочется (в том числе и заказчику) автоматизации, чтоб заказчик сам рисовал схему процессов и пускал её в работу.

M>Мухи и котлеты.....

M>Нафиг-нафиг. Во-первых я не встречал еще ни одной нотации, ктороая бы смогла однозначно описать модель да еще и на языке программиста, а во-вторых, я уж тем более не встречал ни одного заказчика четко понимающего что он хочет.
M>Поэтому если уж между заказчиком и системой стоит программист, то пусть общаются словами — оно существенно эффективнее.
Эффективнее если заказчик подвешен за крюк вниз головой (фигурально выражаясь). Беда конечно не в злобном заказчике, а в том, что разработчик и владелец процесса не имеют общего языка. Если заказчик сам будет рисовать схему, то он будет сам нести ответственность за косяки, которые сейчас возникают из-за его недоговорок. При такой схеме подобных проблем возникать вообще не должно.

M>>Время, когда схема, нарисованная заказчиком, будет автоматически пониматься системой (без участия программиста), думаю настанет ещё не скоро.
M>Ну почему же... Уже в 2004 BizTalk-е была чудестная компонента (которую к слову, если я правильно помню, можно выдрать и вставить в свое приложение), которая позволяет прямо в студии, в картинках, описывать некие бизнес-правила, в частности ценообразование, и оные бизнесправила, без малейшего участия программиста вступают в силу, в указанные сроки.
M>Так что заказчицкое счастье в принципе возможно...
Интересно. Посмотрю.

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

M>Жаль.
А чего жалеть, н а то объективные причины есть...

M>По-моему реляционка просто забивает на бизнес-логику.
Ты просто не умеешь ее готовить..

M> Хочется (в том числе и заказчику) автоматизации, чтоб заказчик сам рисовал схему процессов и пускал её в работу.
Хочется — это понятно, другое дело, что хранение данных в виде объектов этому хотению ни сколько не поможет, скорее наоборот.

M>Беда конечно не в злобном заказчике, а в том, что разработчик и владелец процесса не имеют общего языка. Если заказчик сам будет рисовать схему, то он будет сам нести ответственность за косяки, которые сейчас возникают из-за его недоговорок. При такой схеме подобных проблем возникать вообще не должно.
При такой схеме заказчик будет сам виноват только в том случае, если разработчика из схемы исключить полностью, в противном случае это не заказчик не смог объяснить, а разработчик не смог понять. Ну и плюс, лишний шанс допустить ошибку и что-то не так реализовать.

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

AVK>По семантике LINQ ближе к XPath, хотя синтаксически действительно похож на SQL.
Если более точно говорить, то к XQuery.

С уважением, Gleb.

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

AVK>>По семантике LINQ ближе к XPath, хотя синтаксически действительно похож на SQL.
GZ>Если более точно говорить, то к XQuery.

Неа. XQuery в доках поминают исключительно ради красивого словца. А на самом деле чем XQuery кардинально отличается от XPath? Правильно, наличием конструкций для изменения данных. Можно в LINQ делать декларативное изменение данных?

Хотя конечно возможностей у LINQ поболее, чем у XPath.

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

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

AVK>>>По семантике LINQ ближе к XPath, хотя синтаксически действительно похож на SQL.
GZ>>Если более точно говорить, то к XQuery.

AVK>Неа. XQuery в доках поминают исключительно ради красивого словца. А на самом деле чем XQuery кардинально отличается от XPath? Правильно, наличием конструкций для изменения данных. Можно в LINQ делать декларативное изменение данных?
Нету в XQuery — изменения данных. Оно может генерить данные в стиле XSL(или того же IEnumerator<>) но не изменять текущие.
Пример XQuery

for $item in doc("string.xml")//news_item
where contains(string($item/content), "Gorilla Corporation")
return
<item_summary>
{ concat($item/title,". ") }
{ concat($item/date,". ") }
{ string(($item//par)[1]) }
</item_summary>

AVK>Хотя конечно возможностей у LINQ поболее, чем у XPath.
А у XQuery еще больше.
Посмотри их Use Cases. По ним легко узнавать возможности языка. А язык действительно крутой получился.

С уважением, Gleb.

Кстати, что скажете по поводу Sedna?

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

M>Угу, а знаешь почему? Потому что объект != данные. Объект — это поведение, данные же остаются неизменными, отсюда и возникает эта невиданная простота и легкость.
1. Не столь все однозначно. Данные — есть отражение предметной области. Собственно именно эта ошибка допущенная разработчиками SQL, что данные — есть данные а не отражение предметной области и привело к потере идентифицируемости данных и появления дубликатов.
2. Достаточно много структур, под которые реляционка мягко говоря не очень. Ну например, хранение исторических данных. Либо избыточность данных, либо пляски с бубном. Ну не надо мне хранить все прошлые данные, надо хранить только те которые изменились. VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я что-то не видал. Или например иерархические справочники. Я понимаю что решений хоть отбавляй. Их действительно много и из разных красок. Но сама реляционка не поддерживает их.(Oracle с его time series и их иерарх. запросов оставим в стороне, в большинстве баз такого нет).
3. О том что при сращивании объектной модели и реляционной приходится плясать с бубном, уже наверно говорить не стоит. Способность реляционки трансформировать свою схему — конечно многого стоит. Но все равно, лучше бы и без этого.

С уважением, Gleb.

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

GZ>1. Не столь все однозначно.
Ясное дело, что нюансов много, но я ни где и не говорил, что реляционка идеальна.

GZ> Данные — есть отражение предметной области.
Скорее предметная область — отражение данных. Предметная область меняется, а сами данные — нет. Одни и те же данные могут выступать в разном качестве в разных предметных областях — это зависит от способа интерпретации, но ни как не от самих данных.

GZ>2. Достаточно много структур, под которые реляционка мягко говоря не очень. Ну например, хранение исторических данных.
С историческими данными проблем нет, если надо брать срезы, то лучше реляционки это мало кто сделает.

GZ> VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я что-то не видал.
Плохо смотрел. Первое что приходит голову — новый MS-ный TFS, все хранилище в сиквеле, и документы, и VCS, и черт знает что еще...

GZ>Или например иерархические справочники. Я понимаю что решений хоть отбавляй. Их действительно много и из разных красок. Но сама реляционка не поддерживает их.(Oracle с его time series и их иерарх. запросов оставим в стороне, в большинстве баз такого нет).
Что значит не поддерживает? Во-первых с появлением Юкона все три основные СУБД имеют иерархические запросы, при этом у Оракла самый бедный вариант. А во-вторых такая поддержка по большему счету и не нужна, все и без нее реализуется....

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

GZ>> Данные — есть отражение предметной области.
M>Скорее предметная область — отражение данных. Предметная область меняется, а сами данные — нет. Одни и те же данные могут выступать в разном качестве в разных предметных областях — это зависит от способа интерпретации, но ни как не от самих данных.
Если две программы работают в одной предметной области, это не значит что это две предметной области и сущности с разными свойствами. Можешь привести пример?

GZ>>2. Достаточно много структур, под которые реляционка мягко говоря не очень. Ну например, хранение исторических данных.
M>С историческими данными проблем нет, если надо брать срезы, то лучше реляционки это мало кто сделает.
Нет. Я не о срезе. Я об обеспечении среза. Допустим, у нас есть таблица которая отслеживает параметры приборов. Примерная данные {имя_прибора, напряжение, сила тока, сопротивление, время}. Изменяться одновременно могут только два параметра. Оставлять в одной таблице — избыточно. Разбивать по нескольким таблицам — еще избыточней. В ней нельзя отразить изменение только трех параметров.

GZ>> VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я что-то не видал.
M>Плохо смотрел. Первое что приходит голову — новый MS-ный TFS, все хранилище в сиквеле, и документы, и VCS, и черт знает что еще...
А TFS тут причем. Он разве хранит версии? Во вторых, для реляционки такие тексты — не более чем блобье(если конечно он не сохраняет их в xml, что ненамного лучше).

M>Что значит не поддерживает? Во-первых с появлением Юкона все три основные СУБД имеют иерархические запросы, при этом у Оракла самый бедный вариант. А во-вторых такая поддержка по большему счету и не нужна, все и без нее реализуется....
Посмотрел, реализацию. Такой же отстой что и в Oracle. Ну неэффективен доступ в parent child с рекурсивными запросами. На сайте была статейка и там были определены как оценивать эффективность иерархических запросов. Правильная статья, поскольку там есть очень важный и достаточно часто встречающийся запрос — взять всех потомков данной записи. Ручками такое делать эффективнее чем данными механизмами.

С уважением, Gleb.

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

B>Здравствуйте, Mazay, Вы писали:
M>> С объектами же программисты привыкли делать всё, что им заблагорассудится. Можно задать самое извращённое поведение объекта, даже научить его понимать какой-нить язык описания ограничений или запросов. Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL). Или просто обучить заказчика использованию BPEL (или что там будет).
B>Если быть до конца честным, бледное подобие таких движков есть, а именно, я говорю о алгоритмических языках, встроенных в СУБД. Конечно, GUI на них писать пока ещё рано... Хотя есть PostgreSQL, где границы между своим и чужим ЯП практически стёрты.
Можно ли подробнее развить тему?

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

GZ>Если две программы работают в одной предметной области, это не значит что это две предметной области и сущности с разными свойствами. Можешь привести пример?
Причем тут программы? Есть данные, например, плотность населения. Для экономиста и социолога семантика данных совершенно различна и объекты тоже разные, но цифра одна и та же.

GZ> Изменяться одновременно могут только два параметра. Оставлять в одной таблице — избыточно. Разбивать по нескольким таблицам — еще избыточней.
Уйти от избыточности в данной задаче проблем нет, другое дело что я не вижу причины уходить, ведь в конечном итоге важна эффективность и реляционка ее обеспечит наилучшим образом.

GZ>А TFS тут причем. Он разве хранит версии?
Ну здрасьте, хранит конечно. Там полноценный навороченый VCS, похлеще Perforce (которого имеет в дальних предках), и это не считая совершенно безумной иерархии документов с поддержкой той же истории. Да, и баг-трекинг туда же...

GZ> Во вторых, для реляционки такие тексты — не более чем блобье(если конечно он не сохраняет их в xml, что ненамного лучше).
Какая разница, блобы это или нет? Помимо самих текстов важны метаданные и тут реляционка себя проявляет в полный рост.

GZ>Посмотрел, реализацию. Такой же отстой что и в Oracle.
Значит плохо посмотрел.

GZ> Ну неэффективен доступ в parent child с рекурсивными запросами.
Шашечки или ехать? Если нужно удобство, то вот тебе простые запросы, к слову достаточно эффективные.
Если нужна действительно высокая производительность, то тогда делаем ручками в той же реляционке, потому как с объектами все равно получится хуже, если только хранение этих объектов специально под иерархию не заточено, да и то надо смотреть...

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

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

GZ>>Если две программы работают в одной предметной области, это не значит что это две предметной области и сущности с разными свойствами. Можешь привести пример?
M>Причем тут программы? Есть данные, например, плотность населения. Для экономиста и социолога семантика данных совершенно различна и объекты тоже разные, но цифра одна и та же.
Я бы так не сказал. Если ты вложишь в данную сущность противоречивые свойства (а исходя из посыла, что это данные а не объект, то такое возможно), то кто-то из них работать не будет. Если у тебя есть счет, то независимо от того для чего ты его используешь, для анализа или проводок, для построения баланса или еще чего, он остается счетом. Ты можешь выцеплять различные его свойства, но они не должны противоречить ни друг другу, ни самому понятию счет. Поэтому отношение к данным, как просто к набору строк — неверно. За данными всегда кроется семантика их сущности.

GZ>> Изменяться одновременно могут только два параметра. Оставлять в одной таблице — избыточно. Разбивать по нескольким таблицам — еще избыточней.
M>Уйти от избыточности в данной задаче проблем нет, другое дело что я не вижу причины уходить, ведь в конечном итоге важна эффективность и реляционка ее обеспечит наилучшим образом.
У тебя генерятся гигабайты информации. Притом избыточные гигабайты. И при этом ты говоришь об эффективности?
Избыточность информации может увеличить эффективность реляционной БД. Но переизбыток информации, уже нет. И даже индексы не спасут, потому как они сами по себе гигабайтные и их надо заполнять. И не все операции возможно делать именно через seek индекса.

GZ>>Посмотрел, реализацию. Такой же отстой что и в Oracle.
M>Значит плохо посмотрел.
Уж как умею.

GZ>> Ну неэффективен доступ в parent child с рекурсивными запросами.
M>Шашечки или ехать? Если нужно удобство, то вот тебе простые запросы, к слову достаточно эффективные.
M>Если нужна действительно высокая производительность, то тогда делаем ручками в той же реляционке, потому как с объектами все равно получится хуже, если только хранение этих объектов специально под иерархию не заточено, да и то надо смотреть...
ЭЭЭЭ. Реляционка предоставляет очень быструю реализацию реляционных структур. При разработке, было все положено для реализации максимально быстрой БД. И отношение к БД то, что ее основное качество быстрота, сохранилось и сейчас. И начиная с времен SystemR она оценивалась прежде всего с этой стороны. Так почему сейчас нас накормили полумерами?

С уважением, Gleb.

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

GZ>Если ты вложишь в данную сущность противоречивые свойства (а исходя из посыла, что это данные а не объект, то такое возможно), то кто-то из них работать не будет.
Я не могу заложить в сущность противоречивые свойства так как сущности у меня пока нет. У меня есть данные, а сущность — это вопрос интерпретации этих данных.

GZ>Если у тебя есть счет, то независимо от того для чего ты его используешь, для анализа или проводок, для построения баланса или еще чего, он остается счетом.
У меня нет счета. У меня есть данные, вот если я на их основе создам объект "счет", вот тогда я буду работать с ними как со счетом, но это уже другая исторя. Если же у меня изначально не данные, а именно "счет", то очень велик шанс, что объект "счет" окажется не достаточно универсальным, чтобы удовлетворить все запросы к данным которые он в себе содержит и тогда количество геморроя на строчку кода по извлечению этих данных превзойдет самые смелые ожидания. А вот если у нас данные это просто данные то такая проблема вообще не стоит, на этом реляционка и держится. Потому что даже сейчас используются те самые цифры, которые вбивались в реляционные БД более 20 лет назад. И базы уже другие, и железо другое, и анализируют эти цифры совсем другие программы и совсем по другим алгоритмам, только цифры остались прежними, и получилось так именно потому, что реляционная модель, работает с данными, а не с их интерпретацией.

GZ> Ты можешь выцеплять различные его свойства, но они не должны противоречить ни друг другу, ни самому понятию счет.
Нет такой проблемы. Точнее это проблема непротиворечивого представления объекта, и она вылезет в любом случае.

GZ> Поэтому отношение к данным, как просто к набору строк — неверно. За данными всегда кроется семантика их сущности.
Проблема в том, что семантика меняется, а цифры остаются те же. И надо использовать те же цифры, но по другому. А если завязываться на семантику, то использовать те же цифры будет очень проблематично.
Поэтому к данным надо относиться именно как к данным, завязываясь (на низком уровне) на их семантику только в самом крайнем случае.

GZ>У тебя генерятся гигабайты информации. Притом избыточные гигабайты. И при этом ты говоришь об эффективности?
Именно. Гигабайты по нонешним меркам — не объем, да и уйти от избыточности не сложно.

GZ> Так почему сейчас нас накормили полумерами?
Можешь предложить вариант лучше?