Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как правильно сохранить в базу массив Double?

Страницы: 1 2 >
Kolan © (2008-06-29 12:34:00)
Здравствуйте,
Мне нужно сохранить в базу массив чисел типа Double. Массив может содержать до 100000х4 = 400000значений, но обычно это где-то 400х4=1600 чисел.

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

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

Petr V. Abramov (2008-07-07 02:00:00) [1]
пока задача не озвучена, ветка - островок потрепаловки в "Базах"

Kolan (2008-07-06 17:59:00) [2]
> Просчитай только хватит ли тебе

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

Anatoly Podgoretsky (2008-07-03 13:55:00) [3]
Координаты - это и есть сами измерения?

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

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

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

Kolan (2008-07-03 13:12:00) [4]

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

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

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

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

Desdechado (2008-07-03 10:50:00) [5]

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

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

Anatoly Podgoretsky (2008-07-03 10:38:00) [6]
> Kolan (03.07.2008 10:17:17) [17]

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

Kolan (2008-07-03 10:17:00) [7]
Вариант с таблицей мне очень понравился. Получилось так:
Charts PointID [int] IDENTITY (1, 1) NOT NULL MeasurmentID [int] NOT NULL ChartType [int] NULL X [float] NULL Y [float] NULL
А на накладные расходы я плевал. :)

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

Anatoly Podgoretsky (2008-07-03 07:12:00) [8]
> Petr V. Abramov (03.07.2008 2:43:15) [15]

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

Petr V. Abramov (2008-07-03 02:43:00) [9]

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

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

Desdechado (2008-07-02 20:57:00) [10]

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

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

Petr V. Abramov (2008-07-02 20:07:00) [11]
> Но сколько видел задач, которые постулировали необходимость "только целиком",
например, если массив - это картинка в каком-нить формате.

Anatoly Podgoretsky (2008-07-02 18:41:00) [12]

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

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

Desdechado (2008-07-02 18:27:00) [13]

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

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

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

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

Jeer (2008-07-02 18:09:00) [14]
Как вариант:

table Area:
id
area_rows
area_cols

table AreaValues:
area_id
value: double

Поросенок Винни-Пух (2008-07-02 18:03:00) [15]
Имхо, таблица должна хранится в таблице, а не поле.

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

Jeer (2008-07-02 18:01:00) [16]
Угу.
И пересоздавать таблицы при изменении размерности массива непременно и обязательно.

Kolan (2008-07-02 14:03:00) [17]
> Имхо, таблица должна хранится в таблице, а не поле.
> Тем более, что наверняка найдутся ее применения для расчета
> на сервере, а парсить блобы — занятие неблагодарное и медленное.

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

Desdechado (2008-07-02 11:30:00) [18]
Имхо, таблица должна хранится в таблице, а не поле.
Тем более, что наверняка найдутся ее применения для расчета на сервере, а парсить блобы - занятие неблагодарное и медленное.

Поросенок Винни-Пух (2008-07-02 09:39:00) [19]
ты где собираешься с массивом работать как с массивом?
на клиенте?
тогда тебе вообще не нужен массив расчесанный в таблицу. сохраняется одним блоком памяти.

Kolan (2008-07-02 09:13:00) [20]
> ну и магистры нынче пошли.

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

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

Хм...

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »