Здравствуйте,
 Мне нужно сохранить в базу массив чисел типа Double. Массив может содержать до
значений, но обычно это где-то 400х4=1600 чисел.

Использую MS SQL Server 2000.

Что для этого использовать?
 1. BLOB? Если да, то где взять примеры или книжку по работе с этим полем (я не работал с BLOB)?
 2. Может как текст его сохранять? Тогда какого типа поле использовать?

ну и магистры нынче пошли.

> 1. BLOB?


Да


> 2. Может как текст его сохранять? Тогда какого типа поле
> использовать?


BLOB


> то где взять примеры или книжку по работе с этим полем


У TField есть все необходимые методы для работы с БЛОБ-полями. Сохраняй в TMemoryStream, а из TMemoryStream'a - в свой массив. И наоборот.

> Kolan  (29.06.2008 12:34:00)  [0]

MS SQL 2000 не поддерживает таких длинных текстовых полей. Остается один из вариантов BLOB или отдельная нормальная таблица.

> ну и магистры нынче пошли.

Я же аналитик :)


> отдельная нормальная таблица

Хм...

Массив — это измерение. Правильно ли я понял, что предлагается сделать таблицу:


?

И насколько это правильное решение?

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

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

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

Мне тоже понравилось это решение, как-то сам не догадался. Всегда можно будет увидеть массив, или сохранить еще что-нить. Так и сделаю.

Угу.
И пересоздавать таблицы при изменении размерности массива непременно и обязательно.

Имхо, таблица должна хранится в таблице, а не поле.

Особенно когда она нужна вся целиком, а не отдельными фрагментами.

Как вариант:

table Area:
id
area_rows
area_cols

table AreaValues:
area_id
value: double

> И пересоздавать таблицы при изменении размерности массива
> непременно и обязательно.

Это если делать "в лоб". А если делать "с умом", то таблица будет состоять из полей вида "координата 1, координата 2, ... координата N, значение ячейки по этим координатам". Количество измерений, имхо, меняется совсем не часто. При этом пустые значения можно не хранить.

> Особенно когда она нужна вся целиком, а не отдельными фрагментами.

Это от задачи зависит. Но сколько видел задач, которые постулировали необходимость "только целиком", все равно находились отдельные тонкости, которым достаточно было части данных. И эти тонкости использовались чаще.

> И пересоздавать таблицы при изменении размерности массива
> непременно и обязательно.

Откуда взялись размерности, и как с ними поможет БЛОБ поле.

> Но сколько видел задач, которые постулировали необходимость "только целиком",
например, если массив - это картинка в каком-нить формате.

> Petr V. Abramov ©   (02.07.08 20:07) [13]

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

> Если уж ты картинку представляешь в виде массива, значит,
>  тебе явно нужна обработка отдельных точек.
> Desdechado ©   (02.07.08 20:57) [14]

только это не на SQL делается, и массив виде одна-запись-один-элемент бессмысленен. Если даже самые продвинутые расширения СУБД умеют делать запрос вида "все картинки, где часть тела between :value and :value",
они это делают через спец. ф-ции работы с BLOB.

> Petr V. Abramov  (03.07.2008 2:43:15)  [15]

Зачем путать массив измерений с картинкой, как бы массив.

Вариант с таблицей мне очень понравился. Получилось так:


А на накладные расходы я плевал. :)

Благодарю за совет — сам бы не додумался.

> Kolan  (03.07.2008 10:17:17)  [17]

Если в измерение есть разные ChartType то позволит выбирать не весь объем.
А что такое X, Y не понятно.

> они это делают через спец. ф-ции работы с BLOB.

Для того, чтоб такая функция сработала, нужно чтение и переваривание ВСЕГО блоба, а не 10 простых чисел по индексу. Еще не известно, что эффективнее.

> А что такое X, Y не понятно.


Ну координаты точки вестимо. По оси абсцисс и ординат...


> Если в измерение есть разные ChartType то позволит выбирать
> не весь объем.

Измерение состоит из трёх больших графиков и трёх маленьких(три точки). У всех у них разный ChartType

Координаты - это и есть сами измерения?

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

PointID [int] IDENTITY (1, 1) NOT NULL

Не нужно ли BigInt
Например с учетом количество измерений*3, что бы потом не больно было с переделкой.

> Просчитай только хватит ли тебе

Наверняка не хватит, благодарю, исправлю.

пока задача не озвучена, ветка - островок потрепаловки в "Базах"