Блок А.Н.
Sergei ObrastsovА как хранятся массивы в других системах, не задумывались? :)
Не надо отвечать вопросом на вопрос, загадочно подразумевая что все дураки, и только вы умный.

Я не увидел там вопроса. Одни утверждения, причем сомнительные.


А многомерная база данных подразумевает равенство всех измерений массива.
В каше этого нет.

Вот те на. А что же есть в Cache? Или без жестких ограничений и программировать неинтересно?


Я не вижу вашего решения, но вряд ли вы что-то придумали кроме прямого перебора.
А в "боевых" системах это неприемлимо.

Ой. А что же такого еще есть в "боевых" системах, окромя индексов? Ничего нету, правда?
Ну так и здесь та же фигня.


Нда... Тут уж нам с krvsa есть повод выдержать многозначительную паузу.
Для начала, Сергей, поищите что такое нормализация и нафига она нужна?

"Для начала" не надо считать других глупее себя. Это так, к слову.


Это ответ на то, зачем нужно много таблиц.

Это неправильный ответ. Из серии "нас только так учили и по-другому мы не умеем".


Да и в целом решение типв ^Global(тип, производитель, цвет, размер, год выпуска)
В данном случае не приемлимо!
Вы можете считать, но не сбивайте людей.
Сделав один такой индекс, вы сами себя бьете по рукам.
Если хотя бы предполагаются запросы типа "выбрать все для данного года выпуска", то практически сложно что-то придумать кроме прямого перебора всех узлов.
А представьте, что данные занимают пару гигов хотя бы? И запросов будет ну хотя бы штук 10 =в секунду? Что вы будете делать в этом случае? Городить рядом еще один индексный глобал?
Можно и так, но зачем с самого начала надевать штаны через голову?

Не надо утрировать, хорошо? У человека простенькая задачка, максимум сотня-две записей.
Вид запросов, надо полагать, он себе представляет прекрасно. Значит его эта структура устраивает. Кроме того, на таком объеме можно позволить себе и не заморачиваться с лишней
индексацией, хватит и того, что есть. Выигрыш? Уже существующий основной индекс и отсутствие
кучи таблиц. Все остальное можно сделать.

А теперь по существу. Нет, я не предлагаю именно так структурировать БД. Нет, я так не делаю
и не считаю это правильным. Только возможным. Доступно?


^Global(тип, производитель, цвет, размер, год выпуска)
имеет смысл, но когда каждый следующий индекс не имеет смысла без предыдущего.
Например информация о классах каше хранится в структуре типа
^oddDEF(класс,"a",поле,15)=тип_поля
В данном случае имя поля не имеет смысла без имени класса, и код значения 15 бессмысленен без класса и поля
Пожалуйста, не надо мне пояснять что такое иерархическая структура, я догадываюсь и так.

Выводы:
1. Мне так и не доказали отсутствие многомерности в Cache. Ссылки на MDBMS несколько
неуместны, мало ли у кого какие тараканы в избе. Никто не запрещает мне делать "кубы" или
прочие массивы равной размерности.
2. С "псевдо-массивами" в Cache тоже пролет. Не надо смешивать горячее с зеленым .
Я про логическое восприятие массивов данных и их физическое воплощение. Трудно реляционщикам с иерархическими структурами, все время хочется их подогнать под привычное.
Сочувствую, много теряется при таком подходе.
3. Мы до этого еще не дошли, но я уже чувствую, что вопрос о "переборе" обязательно возникнет.
Сразу напомню, что "перебор" есть везде. Даже если он скрыт в исполнителе запросов.
4. Жаль, что вы мне так и не ответили на поставленные мною вопросы. И вообще уклонились от темы массивов и индексов. А зря. :)

Блок А.Н. Sergei Obrastsov Блок А.Н.решение типа ^Global(тип, производитель, цвет, размер, год выпуска)
Нет, я не предлагаю именно так структурировать БД. Нет, я так не делаю
и не считаю это правильным.

Нифига себе поворот. Я столько с вами спорю, доказывая, что в данном случае такое хранение неоправдано - и вот те раз, оказывается вы тоже так считаете.
О чем спор то?

Что значит "оправдано/неоправдано"? Человек говорит об использовании данных в индексах
и как пример приводит гипотетическую задачу. Вы с kvrsa уже наворачиваете на это гигабайтное
хранение и прочие премудорости? Нафига так утрировать-то? Что касается меня, то у меня таких
простеньких задач нет, поэтому приходится использовать более общие подходы.


Утверждение, что многомерность подразумевает равность измерений вы проигнорировали.

Я всегда полагал, что многомерность равна многоуровневости. Причем тут равность измерений?


А руками знаете, и в аксесе можно сделать "многомерность". У нас аксес тоже "многомерная" СУБД ?

Access - плоские таблицы. Где вы там собрались делать многомерность?


Глобалы - не многомерные кубы, с этим согласитесь?

Глобалы - это глобалы. А уж что я из них захочу сделать, то и получится. И одномерные массивы,
и плоские таблицы, и многомерные "кубы", если захотите.


Я признал, что логически глобалы можно считать массивами.

Честь и хвала. Осталось только убедиться в том, что из них можно делать все, что угодно.
Поскольку они не фиксированы размерностью.


Перебор есть не всегда. Но в любом случае даже если мне надо выбрать 100 записей из 100000000 - я не пойду прямым перебором

А я говорил про прямой перебор? По-моему речь шла о переборе вообще. Разве я отрицаю
необходимость индексов?


Суть вопроса, что автор создал "массив" данных и теперь не может с ним нормально работать.
Причина ошибки в том, что автор ошибочно считал измерения "массива" равноправными.
А я вот считаю, что эта структура - дерево, а не массив.

В Cache, как и вообще в M, все структуры - деревья. И одновременно массивы.
Может хватит уже так уклончиво об этом говорить. Почему это X(A1,A2) - это массив,
а ^X(A1,A2) - уже нет? А что насчет структуры автора, то я не думаю, что ему потребуются
запросы типа "количество процессоров с разбивкой по производителям".


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

Это ваше право, опять же. Только к нему вы пристроите минимум 3 индекса и получите 6 массивов. Учитывая что многофункциональных запросов к этой задаче быть не может, то возникает вопрос - а нафига этот огород нужен? Чтобы как у всех?

Блок А.Н.Когда мы говорим о неоптимальности, вы говорите "задача на сотню-другую записей", а когда о занимаемом месте - "гигабайтное хранение". Вы уж определитесь как-нибудь.

Про "гигабайты" заговорили вы, а не я.


В данной задаче (по крайней мере той части, что мы видели) хранение данных в индексах как зайцу пятая нога. И вы конечно же это понимате, но из каких-то принципов сопротивляетесь.

Я не вижу в этом ничего плохого. В условиях этой задачи.


Sergei ObrastsovЯ всегда полагал, что многомерность равна многоуровневости. Причем тут равность измерений?
Неверно. Сколько уровней в здании, где вы работает и сколько размерностей?
В размерностях вы можете перемещаться в любой сторону - вправо, влево и даже подпрыгнуть вверх, а вот по уровням (этажам) вам приедтся перемещаться последовательно.

То есть двумерный массив, это не A(x,y), как я полагал, а A(1-2)? Я вас правильно понял?


Sergei ObrastsovAccess - плоские таблицы. Где вы там собрались делать многомерность?
Каше - деревья. Однако же сделали и таблицы и классы.

В Cache можно сделать почти все, а вот наоборот вряд ли получится. Потому повторяю вопрос.


Sergei ObrastsovА я говорил про прямой перебор? По-моему речь шла о переборе вообще. Разве я отрицаю необходимость индексов?
В предложенной автором задаче остается примой перебор (из-за неоптимального проектирования данных). А индексы - да, это "гигабайтное хранение", вы его отрицаете.

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


А я вот таких предположений что "не потребуется" не делаю (и опыт подтверждает - да, скорее всего потребуется). И куда потом идти с таким единственным жестко заданым индексом? Прямой перебор?

Нет, дополнительные индексы. Как и у вас. Если вдруг возникнет такая необходимость.
Хотя, если она вдруг возникнет, то встанет вопрос об осмысленности первоначальной структуры.


Такое ощущение, что вы в курсе задачи и сами предложили автору такое хранение?
Пока только этим объясняется такое яростное отстаивание этого типа хранения (неоправданного на мой взгляд) и такие для пророческие(для постороннего человека) утверждения.

Просто я представляю что он делает.