ну, фиг знает, по моему, в сях это один хрен. А для особого изврата можно тудыть еще и код для самораспаковки и самоинтерпретации запесочить.
> БЛОБ не поддерживается некоторыми субд.
согласен, но многими поддерживается.
> при таком подходе будет нарушена 1-я нормальная форма,
Нормализуй, но знай меру. В этих хитрых книжках так и говорится, что иногда жертвуют нормализацией взамен оптимизации БД, в этом случае часть работы переходит на интерфейс (т.е. на клиента). Иногда это очень даже оправдано.
Хранят же в БЛОБе картики. И ты же не станешь распихивать отдельные пикселы по таблицам, а потом нормализовать. Ежели те столбцы, которые переменные, составляют некую логически законченную еденицу, то БЛОБ - это абсолютно верное решение.
> чем плохо несоблюдение 1-й н.ф.? хотя бы тем, что в > select'е нельзя будет использовать "атрибуты", входящие в > состав BLOB-поля.
А я так понял в задаче Чела этого и нетребуется
> между тем, проблема, которой все испугались, и не проблема > вовсе, если почитать описание ODBC API. Используя ODBC API, > можно узнавать программно сколько > атрибутов на данный момент имеется в данной таблице и > выполнять те или иные действия в зависимости от их числа, > при этом и с выборкой из таких таблиц "переменной ширины":) > тоже никаких проблем не будет. Проблема только в том, что > ODBC API очень низкоуровневый.
Атрибуты посмотреть можно. Но ему-то вроде как надо хранить переменное кол-во столбцов. Если бы он заранее знал их кол-во, наверное и вопрос-то не задавал.
> PS. возможно, все это можно проделать с использованием OLE > DB или еще чего, врать не стану. Я юзал только ODBC, а > давным-давно - MFC CDatabase+CRecordset.
OLE DB - говорят что перспективней, только и всего.
> В любом случае, использование BLOB считаю > безумием.
Попытка - не пытка.
А еще здесь есть один плюс - можно сделать переменное кол-во столбцов для каждой записи в таблице, если конечно это надо.
необходимо создать API для работы с "динамической DB". Т.е. количество полей в таблицах зарание не извесно.
Есть, имхо, два пути:
1. Использовать ALTER TABLE ADD
2. Использовать одно поле BLOB для хранения сериализованых рекордов.
Никаких select по "динамическим" полям делать не надо.
Что лучше ? Есть ли подводные камини при использовании первого метода ?
Предпологается использовать базы: access, oracle, ms sql; возможно foxpro, paradox, my sql.
Пока программный доступ через ado.
[C++] Совет нужен по DB21.05.02 12:47 Автор: BILIA Статус: Незарегистрированный пользователь
На мой взгляд правильнее использовать 1 ый вариант
> 1. Использовать ALTER TABLE ADD > 2. Использовать одно поле BLOB Открытая система проще в разработке и поддержке.
[C++] Совет нужен по DB21.05.02 21:39 Автор: + <Mikhail> Статус: Elderman
> На мой взгляд правильнее использовать 1 ый вариант > > 1. Использовать ALTER TABLE ADD > > 2. Использовать одно поле BLOB > Открытая система проще в разработке и поддержке.
I by ispolzoval vtoroi metod i hranil dannye v XML formate. togda legko mozhno dobavliat/udaliat pole. i legko parsirovat XML.
ALTER TABLE ADD na skolko I pomni na Raznyh SQL vedet sebia po raznomu, k tomu zhe eta operacia mnogo resursov potrebliaet.
Вот в том и проблемма22.05.02 17:35 Автор: PS <PS> Статус: Elderman
Что метаюсь между двух этих идей. Большее количество рессурсов - не является проблеммой. Система не real time - так что может и подождать.
Хотелось бы точно узнать какие именно SQL сервера не поддерживают динамическое изменение структуры (если такие вообще есть), и на каких работа присходит не корректно.
Сегодня протестировал Access, MS SQL, Oracle - никаких сбоев не обнаружил. Работают как часы.
> > На мой взгляд правильнее использовать 1 ый вариант > > > 1. Использовать ALTER TABLE ADD > > > 2. Использовать одно поле BLOB > > Открытая система проще в разработке и поддержке. > > I by ispolzoval vtoroi metod i hranil dannye v XML > formate. togda legko mozhno dobavliat/udaliat pole. i > legko parsirovat XML. > > ALTER TABLE ADD na skolko I pomni na Raznyh SQL vedet sebia > po raznomu, k tomu zhe eta operacia mnogo resursov > potrebliaet.
Я за второй способ23.05.02 00:46 Автор: whiletrue <Роман> Статус: Elderman
Хотя, на сколько я понимаю, тогда много чего ляжет на смотрящую эту базу прогу.
К примеру, если реализовывать ее на Visual C, то этот способ на много лучше, т.к. там на кусман памяти можно наложить какую хочешь заранее заданную структуру, да и сами наборы данных из баз там подобным образом и представляются. Так что все пишется вполне естественно.
А если пишешь на Дельфи, то лучше ALTER TABLE. Т.к. там вся работа с памятью (да и сданными), сделана как-то через задницу. Такое ощущение, что, ALTER TABLE пройдет быстрее.
а как же нормализация БД? или Дэйта никто не читал?23.05.02 04:04 Автор: йцукенг <jcukeng> Статус: Member
рассмотрим критически так понравившийся всем подход.
с БЛОБ работа идет через ж.
БЛОБ не поддерживается некоторыми субд.
при таком подходе будет нарушена 1-я нормальная форма, и это самое плохое из перечисленного.
для тех кто в танке - отношение находится в 1-й нормальной форме, если все атрибуты - скаляры, т.е. нет составных атрибутов.
чем плохо несоблюдение 1-й н.ф.? хотя бы тем, что в select'е нельзя будет использовать "атрибуты", входящие в состав BLOB-поля.
между тем, проблема, которой все испугались, и не проблема вовсе, если почитать описание ODBC API. Используя ODBC API, можно узнавать программно сколько атрибутов на данный момент имеется в данной таблице и выполнять те или иные действия в зависимости от их числа, при этом и с выборкой из таких таблиц "переменной ширины":) тоже никаких проблем не будет. Проблема только в том, что ODBC API очень низкоуровневый.
PS. возможно, все это можно проделать с использованием OLE DB или еще чего, врать не стану. Я юзал только ODBC, а давным-давно - MFC CDatabase+CRecordset.
В любом случае, использование BLOB считаю безумием.
нормализуй но в меру23.05.02 23:09 Автор: whiletrue <Роман> Статус: Elderman
ну, фиг знает, по моему, в сях это один хрен. А для особого изврата можно тудыть еще и код для самораспаковки и самоинтерпретации запесочить.
> БЛОБ не поддерживается некоторыми субд.
согласен, но многими поддерживается.
> при таком подходе будет нарушена 1-я нормальная форма,
Нормализуй, но знай меру. В этих хитрых книжках так и говорится, что иногда жертвуют нормализацией взамен оптимизации БД, в этом случае часть работы переходит на интерфейс (т.е. на клиента). Иногда это очень даже оправдано.
Хранят же в БЛОБе картики. И ты же не станешь распихивать отдельные пикселы по таблицам, а потом нормализовать. Ежели те столбцы, которые переменные, составляют некую логически законченную еденицу, то БЛОБ - это абсолютно верное решение.
> чем плохо несоблюдение 1-й н.ф.? хотя бы тем, что в > select'е нельзя будет использовать "атрибуты", входящие в > состав BLOB-поля.
А я так понял в задаче Чела этого и нетребуется
> между тем, проблема, которой все испугались, и не проблема > вовсе, если почитать описание ODBC API. Используя ODBC API, > можно узнавать программно сколько > атрибутов на данный момент имеется в данной таблице и > выполнять те или иные действия в зависимости от их числа, > при этом и с выборкой из таких таблиц "переменной ширины":) > тоже никаких проблем не будет. Проблема только в том, что > ODBC API очень низкоуровневый.
Атрибуты посмотреть можно. Но ему-то вроде как надо хранить переменное кол-во столбцов. Если бы он заранее знал их кол-во, наверное и вопрос-то не задавал.
> PS. возможно, все это можно проделать с использованием OLE > DB или еще чего, врать не стану. Я юзал только ODBC, а > давным-давно - MFC CDatabase+CRecordset.
OLE DB - говорят что перспективней, только и всего.
> В любом случае, использование BLOB считаю > безумием.
Попытка - не пытка.
А еще здесь есть один плюс - можно сделать переменное кол-во столбцов для каждой записи в таблице, если конечно это надо.
нормализуй но в меру24.05.02 03:52 Автор: йцукенг <jcukeng> Статус: Member
Я> > при таком подходе будет нарушена 1-я нормальная форма,
Вы>
> Нормализуй, но знай меру. В этих хитрых книжках так и > говорится, что иногда жертвуют нормализацией взамен > оптимизации БД, в этом случае часть работы переходит на > интерфейс (т.е. на клиента). Иногда это очень даже > оправдано. Видите ли, 1-й формой как-то не принято жертвовать, тем более что в данном случае для этого нет серьезных оснований.
> > Хранят же в БЛОБе картики. И ты же не станешь распихивать > отдельные пикселы по таблицам, а потом нормализовать. Это потому что пиксел не рассматривают как отдельную сущность, с которой надо манипулировать средствами БД.
> Атрибуты посмотреть можно. Но ему-то вроде как надо хранить > переменное кол-во столбцов. Если бы он заранее знал их > кол-во, наверное и вопрос-то не задавал. Мне кажется, Вы не поняли вопроса.
Если в одной строке 5 столбцов, в другой 4, в третьей - три, то это не таблица будет. А реляционные БД тем и отличаются, что данные хранятся в таблицах.
Когда число столбцов в таблице увеличивается с временем с помощью alter table, при использовании ODBC API нет ничего особо сложного.
Я> > В любом случае, использование BLOB считаю
> > безумием. > Вы> Попытка - не пытка.
Ошибка, допущенная на этапе проектирования обходится очень дорого.
Сейчас "Никаких select по "динамическим" полям делать не надо."
А представьте, например, что через какое-то время понадобится делать выборку, которая в where использует атрибут спрятанный в BLOB. Что тогда придется делать? Либо использовать курсоры, что сильно замедляет работу БД, либо делать выборку без учета этого атрибута, а затем в программе из (возможно, очень большого) множества кортежей выбирать пару строк, отвечающие критерию.
> А еще здесь есть один плюс - можно сделать переменное > кол-во столбцов для каждой записи в таблице, если конечно > это надо. Число столбцов в таблице с т.зр. СУБД будет вовсе не переменным. BLOB-атрибут это 1 столбец.
нормализуй но в меру24.05.02 00:08 Автор: + <Mikhail> Статус: Elderman
> a SAMYI LUCHIII VARIANT DOBAVIT 3 TABLICY. > 1- hraint novye fields, 2- types, 3 - values, > I vse budet normalizovano.
Кстати говоря, я тут поразмыслил мозгами.
Нужно отношение tabl <-> values много ко многим, т.е. нужно завести еще промежуточную таблицу.
А, таблица types - получиться как бы просто информационной (для разбивки values по группам, и может представлять собой вообще даже какое-нибудь дерево... О как).
> > > a SAMYI LUCHIII VARIANT DOBAVIT 3 TABLICY. > > > 1- hraint novye fields, 2- types, 3 - values, > > > I vse budet normalizovano. > > как это в третьей таблице одни values хранить, да разных > типов? > или к ней тоже ALTER TABLE ADD применять? > тогда смысл в чем? > растолкуите, plz
или... тот же БЛОБ :)))24.05.02 23:15 Автор: whiletrue <Роман> Статус: Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
