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

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

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

Сохранить массив в БД [D6, Access 2003]

Галинка © (2006-05-08 23:25:00)
Доброго времени суток!

Есть необходимость сохранить массив (примерно 1260 значений; real) в БД. Пока остановилась на Аксесе, но это не определено. Краем уха слышала, что для этого подходят BLOB-поля.

Что можете посоветовать. Лучше источники.

Val (2006-05-11 16:08:00) [1]
>Галинка ©
как

> Таскать с собой и базу (она уже есть и это не обсуждается)

соотносится с

> Пока остановилась на Аксесе, но это не определено.

?
Путаете людей - получаете противоречивые ответы(но верные и хорошие, подчеркну).

Галинка (2006-05-11 15:57:00) [2]
Stanislav, ну хоть кто-то по делу. Я уже нашла это на Королевстве. И заполнять их надо через TBlobString.

Всем остальным. Таскать с собой и базу (она уже есть и это не обсуждается) и папку с текстовыми файлами - это согласитесь не удобно. Удобнее когда все в одном ларчике.

Stanislav (2006-05-11 13:52:00) [3]
В Access есть поле объекта OLE это и есть Blob поле.

Jeer (2006-05-11 13:42:00) [4]
Галинка © (10.05.06 23:53) [14]

Сохраняй результаты в txt файл.
Очень многие известные мат.пакеты и системы обработки вполне этим довольствуются.

Галинка (2006-05-10 23:53:00) [5]
Цель базы не передача данных, а сохранение результатов для аналица. База - это цель. Обработка одного из полейв Матлабе - это лишь часть проекта, потому что в Матлабе проще обрабатывать матрицы.

ПыСы: если найду как сохранять средствами СОМ рисунки из Матлаб, то не плохо бы и их сохранить ))

AlexWlad (2006-05-10 20:03:00) [6]

> Галинка © (09.05.06 22:22) [5]

Раз не нужен поэлементныйдоступ, стоит посмотреть в сторону типизированных файлов. БД тут лишняя тяжесть.

Desdechado (2006-05-10 11:03:00) [7]
если по уму, то я бы сделал так
таблица из 3 столбцов:
1. номер расчета
2. номер показателя
3. значение показателя (этот самый реал)
тогда все расчеты можно хранить в БД, получать доступ индивидуально как к расчетам, так и к конкретным показателям одного или нескольких расчетов, сравнивать, засовывать в формулы и прочее
выгрузить тоже легко, проще на порядок, чем из блоба (особенно неструктурированного)

Джо (2006-05-09 23:54:00) [8]
Тогда непонятно, почему не устривает обычный человеческий способ хранить данные там, где их положено хранить — в столбцах таблицы? Одно значение — одна строка, тип поля — значение с плавающей точкой или иное, продиктованное задачей и возможностями СУБД.

Галинка (2006-05-09 23:20:00) [9]
Про БД это не я придумала. Это для анализа.

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

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

Джо (2006-05-09 22:54:00) [10]
> [7] Галинка © (09.05.06 22:50)
> Джо, спасибо. Это логично. Но не очень удобно.

Пока не видно НИ ОДНОЙ причины, по которой бы СУБД была более удобной. Или, хотя бы, необходимой.

Галинка (2006-05-09 22:53:00) [11]
А вот в самом Акцесе есть поле типа Мемо. Он говорит, туда мона написать симфольно-цифровые данные "общим весом" до 64 кб. Может сойдет? Его тоже можно в текст как-то быстро перевести?

Или все таки искать другую БД?

Галинка (2006-05-09 22:50:00) [12]
Джо, спасибо. Это логично. Но не очень удобно. Потому как БД мне тоже нужна, а таскать и БД и директорию с такими вот файлами, или каждый раз их пересчитывать, то же морока. Именно поэтому и вопрос, хранятся ли блобы в самом файле БД, чтобы ничего не забыть "при переезде"

А так сделал выборку, сделал конвертацию (ну в смысле из блоб в текст, на время, потом убрал) и получил семейсиво кривых. Крысота и чудеса анализа... (не математического).

Джо (2006-05-09 22:32:00) [13]
Пиши в текстовый файл посредством TStringList.

Галинка (2006-05-09 22:22:00) [14]
DiamondShark © (09.05.06 13:03) [3]
написано же, 1250 элементов типа real.

в отдельную таблицу это не красиво и не корректно наверное, зачем мне таблица с одним столбцом и 1250 записями? И таких таблиц будет много, т.к. это результаты расчета. И мне не нужен поэлементнвй доступ. Мне сорее нужна возможность превратить это поле в текстовый файл.

Это все надо для экспорта пощитанного вектор-столбца во внешнее пиложение, с которым связываюсь посредством COM-сервера.

demon81 (2006-05-09 18:55:00) [15]
Вообще-то в любом случае нагружать таблицу большим количеством полей не стоит, а вот BLOB поля идеально для этого подходят.
MS SQL Server хранит такие данные в одной файле с таблицей (так как все данные у данного сервера хранятся в нескольких файлах, в зависимости от конфигурации БД), в dBase это будут отдельные файлы. Interbase также как и MS SQL server хранит одним файлом. А работать с такими полями удобнее всего через потоки. Любые движки позволяют выделить сырые данные этих полей как есть

DiamondShark (2006-05-09 13:03:00) [16]

> слышала, что для этого подходят BLOB-поля.

Для чего "для этого"?
Если просто хранить неважно_какой_массив_неважно_чего, то, наверное, подходят.
А если нужен поэлементный доступ, то, наверное, отдельная таблица больше бы подошла.

Зачем этот массив нужен, и что с ним дальше будет происходить?

alex-drob (2006-05-09 00:48:00) [17]
Точно не помню, в MySql кажется до определённого размера храняться в базе, а большие в отдельных файлах.

Галинка (2006-05-09 00:21:00) [18]
Должны ли данные для BLOB-полей хранится на диске в файлах, или они хранятся прямо в базе?

Наверх

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