Вопрос по проектированию БД

[Яр]

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

На ум приходят следующие способы хранения:

1) Сериализовать массив и результат добавить в какой-то атрибут отношения.
Что-то вроде следующего:

MYTABLE
pkey1 : INTEGER (PK)
pkey2 : INTEGER (PK)
pkey3 : INTEGER (PK)
serialized_values : TEXT

Вариант отпадает, как противоречащий первой нормальной форме Бойса - атрибут не атомарен.

2) для каждого значения value создаётся отдельный экземпляр отношения, номер определяется первичным ключём.

MYTABLE
pkey1 : INTEGER (PK)
pkey2 : INTEGER (PK)
pkey3 : INTEGER (PK)
pkeyValueId : INTEGER (PK)
value : INTEGER

Здесь проблема в том, что вариант достаточно расточителен . Как упоминалось, отношение слабое, и имеет первичный ключ, состоящий из 3 атрибутов + 1 для идентификации конкретного value. Получается, что всё множество экземпляров отношения занимает уж очень много места. (для каждого атрибута value нужно хранить ещё значения 4 атрибутов первичного ключа).

3) для каждого значения value создаётся отдельный атрибут одного и того же отношения.

MYTABLE
pkey1 : INTEGER (PK)
pkey2 : INTEGER (PK)
pkey3 : INTEGER (PK)
value1 : INTEGER
value2 : INTEGER
value3 : INTEGER
...................
...................
value254 : INTEGER
value255 : INTEGER

По идее, подход лишён недостатков двух предыдущих, но вот, как это будет-то, отношение с 512 атрибутами (+ключи) - это нормально? .

Извините за кое-где вольную терминологию.
Пытался изъясниться понятно
Жду ваших советов. Спасибо за внимание.

[Ull9]

не совсем понял твою вольную терминологию.
Что значит слабое отношение? и что значит "В некотором отношении разрабатываемой БД", что такое отношение БД?
еше неясно "Элементарного типа данных ("массив") нет." почему тип данных массив, элементарный?

дальше, больше. наверно дело в том что я никогда не проектировал БД.

[Яр]

Ull9,
отношение, просто говоря, это таблица. наверно стоило бы сразу так и написать, просто в тех книжках по БД, что я листаю, используется такой термин.

еше неясно "Элементарного типа данных ("массив") нет." почему тип данных массив, элементарный?

Я имел в виду, что нет такого типа данных, как массив в реляционных СУБД (на сколько мне известно).

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

[Ull9]

ок, понятно
ну если б чего на ц++, то тут я что угодно, можно сказать почти гуру, а БД, извини

[Яр]

Ull9,

и на том спасибо ).

[Tigra]

Ох уж эти теоретики)))
Сказал бы по-человечески - надо зафигачить массив в таблицу с foreign keys)))
А я бы сказала - в любом случае хранение массива в базе уже является денормализацией - это раз. Денормализация - не всегда зло - это два.
Из трех же способов приемлемы два - хранение в виде строки с разделителями, и хранение массива в отдельной таблице со ссылкой на родителя.
Какой конкретно - зависит от того, ЧТО ты потом планируешь делать с этим массивом.
Строка - лучший вариант для хранения одномерного массива.
Таблица - лучший вариант для хранения, сортировки и модификации многомерного массива.
А вообще - читай Хендерсона, например... и изъясняйся по-человечески)))))

[x[82]]

Насколько я понял нужно хранить n-ое количество массивов, каждый по 512 переменных?
Если так - 2 таблицы, один-ко-многим.

[Lord of rings]

Я сейчас жутко простуженный - нифига не соображаю. Если подождешь дня 2-3 - попробую вникнуть в суть твоей проблемы.

[Яр]

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

Спасибо всем кто откликнулся,

Tigra,
вариант со строкой с разделителями отпадает как непоходящий, потому как нужно иметь возможность обращаться к разным элементам массива из сред, возможно не поддерживающих сложные операции со строками.
Хранить таблицей - получается что она занимает уж очень много места, потому что у неё выходит 3 первичных ключа + 1 для номера переменной. Сами по себе эти ключи уже весят много больше чем само значение. А ещё, представь, что таких значений сотни, а их количество ещё умножить на 512 значений. Вообщем, вариант не подходит из-за того слишком много весит всё это дело.. + добавление новых значений тоже происходит значительно медленнее.
Например, там при использовании этого метода выходит 20000 rows для нашей таблицы, вышло бы всего (20000/255 =) 78 при использовании строки с разделителями или большой таблицы с 255 атрибутами.

x[82],
вариант с таблицами хорош, но как я уже говорил, в моём случае с тремя первичными ключами + 1 ключ для индексации конкретной переменной массива, на всё это расходуется очень много места.

Lord of rings, конечно подожду

[Tigra]

Яр, кстати,а СУБД какая? Некоторые СУБД (не будем показывать пальцами))) являются, скажем так, расширяемыми - т.е. поддерживают пользовательские функции, процедуры и типы данных
Если твоя - из таких - тогда все совсем хороше.
Если нет, то -
что касается

обращаться к разным элементам массива из сред, возможно не поддерживающих сложные операции со строками

то массив парсить можно и из SQL. Обращение к отдельным элементам будет идти медленее, но (если хорошо написать), то не катастрофически медленно, конечно.
Что же касается

получается что она занимает уж очень много места, потому что у неё выходит 3 первичных ключа + 1 для номера переменной

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

[x[82]]

Места пожалуй нормально так займет
Тогда еще вариант извращения - одна таблица. Все ключи + 512 полей для переменных.

Я сейчас жутко простуженный - нифига не соображаю. Если подождешь дня 2-3 - попробую вникнуть в суть твоей проблемы.

Скорейшего выздоровления

[KoVadim]

Почему боитесь использовать таблицы с большим количеством строк? Думаете будет медленей работать, чем вы распарсите вручную?
Сервера БД специально предназначены для оперирования больщими объёмами. Это их работа.
По поводу, что нет полей типа массив. Есть. В InterBase/FireBird. Точно есть.
Я бы спроектировал бы по простому. Завёл поле индекс и поле значение. По полю индекс сделал бы индекс (масло масляное, но просто так звучит) - это добавило бы заметно скорости. И решило бы ещё 2 проблемы. Вполне может быть, что некоторые значения будут пустыми - мы их просто в базу не заносим. А если завтра тебе окажеться, что массивы должны быть на 1024 элемента?

[x[82]]

Предлагал. Говорит, что места много займет

[KoVadim]

Это всё зависит от того, какие поля. Например FireBird умеет буленовские поля ужимать в один бит (при условии, что их много) или блобы тоже жать до одного бита (если блоб равен null)

Не бойтесь, что база большая. Не пытайтесь "хитро спроектировать" базу, что бы она занимала мало места. Делайте, что бы она работала быстро и не было дублирования данных. И всё будет бегать!

[AmonRa]

Если БД должна занимать минимум места - пишем в двоичный файл, и получаем максимум быстродействия (при прямых руках).
Если забить на объем, а также хочется расширяемости и удобства проектирования - выбираем любой SQL сервер

[AmonRa]

Это всё зависит от того, какие поля. Например FireBird умеет буленовские поля ужимать в один бит

Автор не путает Firebird и Interbase? Нет в Firebird логического типа данных. Кроме того сильно не рекомендуется пользоваться типом данных МАССИВ.

[KoVadim]

FireBird - продолжение InterBase, который хоть и развивается, но как то слабо.
IB7 точно имеет буленовский тип, но размер 32 бита. а FireBird - надо дома книгу открыть точно скажу

[Syon]

А не задумывались уйти от естественных СК к простому искуственному?
Во многих случаях это вполне безболезненно и более того создает как раз экономию в подтаблицах за счет сокращения накладных расходов на foreign keys. (Если я конечно правильно представил структуру баз)

PS. Кроме того, раз все-таки идут обращения к конкретной переменной в массиве, то считать накладные расходы на хранение ее индекса избыточными - это нонсенс.

[pavlentus]

Скоро исскуственный интеллект станет настолько совершенным, что он будет моделировать естественный

[Яр]

Всем спасибо!
буду обдумывать.