Delphi и FireBird (как лучше записать данные)

Всем привет! Интересует следующий вопрос:
Есть БД fdb в ней есть таблица Load(нагрузка) с полями load_id, subj_id, hours, numer_pp. (ид нагрузки, ид предмета, кол-во часов по данному предмету и порядковы номер).
В учебном заведении такая нагрузка формируется для каждой группы и соответственно различается.

Я считаю что легче эти данные записать в массив (числовой), т.е. создать массив нагрузки для каждой группы, а затем записать его в строковое поле или в блоб.
Знаю, что такое можно сделать в php, там есть спец. библиотека которая шифрует и дешифреут данные в строковую переменную, которая потом записыается в строковое поле. (что по словам php-ов ОЧЕНЬ удобно!)
А вот в delphi есть что-нибудь похожее? или ваш вариант? Заранее спасибо!!!

0

Сваливать все данные в одну таблицу, а потом преодолевать собою же воздвигнутые трудности - это как называется?
Вы что-либо слышали про отношение "один-ко-многим" и 3НФ денормализации отношений?

Добавлено через 2 минуты
p.s. возможно я вас не правильно понял.

0

Можно, конечно, запихать созданный массив в что-то типа TStringList, а потом пнуть этот список в одно blob-поле.
Только - оно Вам надо?
Лучше всего всё же помещать каждое значение в отдельное поле и создать отношение Группа->(предмет, нагрузка, часы и проч). С такой базой будет легче работать в разы.

0

Сообщение от arni Сваливать все данные в одну таблицу, а потом преодолевать собою же воздвигнутые трудности - это как называется? Вы что-либо слышали про отношение "один-ко-многим" и 3НФ денормализации отношений? Добавлено через 2 минуты p.s. возможно я вас не правильно понял.

Во первых уважаемый, никто данные в таблицу не сваливал, имеющаяся таблица LOAD - к счастью пуста.
Во вторых 3НФ тут есть (поля load_id, subj_id), вы её просто игнорируете, наверное потому что очень умный ))
И наконец данная задача не отрицает нормализации я лишь спрашиваю как хранить набор данных в одном поле.
К примеру нужно создать таблицу с оценками студентов по предметам, по датам и примечания к оценки, вот в электронных журналах успеваемости как раз такой метод - когда все оценки за 1-ин урок записывабтся в 1-у строку и хранятся в 1-ой записи таблицы, а не создаётся миллион записей о каждой оценке полученной Васей Пупкиным ...

И хотелось бы логичного решения!

Ой, заметил что вы модератор ANRI - извеняюсь за грубость, но наверное вы не так поняли мой вопрос

Добавлено через 2 минуты

Сообщение от Африканыч Можно, конечно, запихать созданный массив в что-то типа TStringList, а потом пнуть этот список в одно blob-поле. Только - оно Вам надо? Лучше всего всё же помещать каждое значение в отдельное поле и создать отношение Группа->(предмет, нагрузка, часы и проч). С такой базой будет легче работать в разы.

Я как раз думал про это! Чтобы создать двемерный массив, где будет код_предмета, кол-во часов, и порядковый номер.
Но вот как записать его в базу, допустим в Blob-поле, у кого-нибудь есть информация на эту тему? буду признателен!

0

TaSSmaN, добавляя такое поле, которе инкапсилирует набор данных, вы разрушаете свою 3НФ со всеми вытекающими.
А то, что бумажный журнал напоминает вам модель много полей внутри одного на каждую запись - так это вам показалось. Просто "стоимость полей" на бумажном носителе ничтожна, а в БД - это элемент структуры, и поэтому не поддается гибкой настройке "по ходу дела", из-за чего и требуется денормализация в подчиненную таблицу, которая в данном случае будет многие-ко-многим. Т.е. там, где на бумаге мы можем расти вширь (столбцы), реляционная структура требует отпочковаться и расти вглубь (строки)

0

Сообщение от arni TaSSmaN, добавляя такое поле, которе инкапсилирует набор данных, вы разрушаете свою 3НФ со всеми вытекающими. А то, что бумажный журнал напоминает вам модель много полей внутри одного на каждую запись - так это вам показалось. Просто "стоимость полей" на бумажном носителе ничтожна, а в БД - это элемент структуры, и поэтому не поддается гибкой настройке "по ходу дела", из-за чего и требуется денормализация в подчиненную таблицу, которая в данном случае будет многие-ко-многим. Т.е. там, где на бумаге мы можем расти вширь (столбцы), реляционная структура требует отпочковаться и расти вглубь (строки)

Хорошо! С точки зрения производительности. Я записываю строку с оценками, ну или массив нагрузки в 1-о пеле к примеру в БЛОБ, 1-ой записи, что на мой взгляд удобнее и быстрее, чем создавать n-ое количество строчек?! Или нет?!
Я бы не сказал что я нарушаю тут 3НФ, у меня же 1-о поле! Содержит 1-о уникальное значение: ну к примеру массив оценок 1А класса за 01.02.2012 или массив нагрузки группы 203!
В таком случае можно считать что и сам тип БЛОБ - приступен к 3НФ, он же её разрушает (если я туда массив забабахаю) по вашим словам получается так!?!?

0

TaSSmaN, современные железки даже не промышленного/серверного, а домашнего варианта за секунды перемалывают таблицы-миллионники при грамотном покрытии индексами и проектировании.
Если количество нормализованных записей не будет упираться в десятки или сотни миллионов штук, значит разговоры о производительности скорее всего беспочвенны.
Кстати, работа с БЛОБами скоростью не отличается, хотя бы потому, что они хранятся на отдельных страницах БД и их все равно придется дофетчивать, пусть не вам в запросе, а серверу прозрачно от вас.
Кроме того, работа ведется всегда с полным содержимым блоба (сколько вы туда намереваетесь засунуть?), что может аукнуться на операциях обновления, где вам вместо атомарного апдейта одного int-значения придется собирать целую коллекцию и передавать её по сети. Это и долго, и не гибко. Такое проектное решение будет вас тяготить со временем.

0

Большое кол-во полей (особенно стринговых) в записи - тормоз в большинстве случаев - раз,
Два - ведет к неэффективности базы (в записи с 1000 полями заполнено только 5, остальные -
лишний груз, что не столько действует на память, которая не занимается пустыми полями, сколько жутко тормозит выборки поскольку индексы вводить на все 1000 полей - дело пьяное)

А уж если 1000 блобов в записи, то это полная хана.

arni говорит дело, а Вы, уважаемый ТС, в [4], как говорится, волну гоните.

0