> с БЛОБ работа идет через ж.
ну, фиг знает, по моему, в сях это один хрен. А для особого изврата можно тудыть еще и код для самораспаковки и самоинтерпретации запесочить.
> БЛОБ не поддерживается некоторыми субд.
согласен, но многими поддерживается.
> при таком подходе будет нарушена 1-я нормальная форма,
Нормализуй, но знай меру. В этих хитрых книжках так и говорится, что иногда жертвуют нормализацией взамен оптимизации БД, в этом случае часть работы переходит на интерфейс (т.е. на клиента). Иногда это очень даже оправдано.
Хранят же в БЛОБе картики. И ты же не станешь распихивать отдельные пикселы по таблицам, а потом нормализовать. Ежели те столбцы, которые переменные, составляют некую логически законченную еденицу, то БЛОБ - это абсолютно верное решение.
> чем плохо несоблюдение 1-й н.ф.? хотя бы тем, что в > select'е нельзя будет использовать "атрибуты", входящие в > состав BLOB-поля.
А я так понял в задаче Чела этого и нетребуется
> между тем, проблема, которой все испугались, и не проблема > вовсе, если почитать описание ODBC API. Используя ODBC API, > можно узнавать программно сколько > атрибутов на данный момент имеется в данной таблице и > выполнять те или иные действия в зависимости от их числа, > при этом и с выборкой из таких таблиц "переменной ширины":) > тоже никаких проблем не будет. Проблема только в том, что > ODBC API очень низкоуровневый.
Атрибуты посмотреть можно. Но ему-то вроде как надо хранить переменное кол-во столбцов. Если бы он заранее знал их кол-во, наверное и вопрос-то не задавал.
> PS. возможно, все это можно проделать с использованием OLE > DB или еще чего, врать не стану. Я юзал только ODBC, а > давным-давно - MFC CDatabase+CRecordset.
OLE DB - говорят что перспективней, только и всего.
> В любом случае, использование BLOB считаю > безумием.
Попытка - не пытка.
А еще здесь есть один плюс - можно сделать переменное кол-во столбцов для каждой записи в таблице, если конечно это надо.
|