Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | |
нормализуй но в меру 23.05.02 23:09 Число просмотров: 925
Автор: whiletrue <Роман> Статус: Elderman
|
> с БЛОБ работа идет через ж.
ну, фиг знает, по моему, в сях это один хрен. А для особого изврата можно тудыть еще и код для самораспаковки и самоинтерпретации запесочить.
> БЛОБ не поддерживается некоторыми субд.
согласен, но многими поддерживается.
> при таком подходе будет нарушена 1-я нормальная форма,
Нормализуй, но знай меру. В этих хитрых книжках так и говорится, что иногда жертвуют нормализацией взамен оптимизации БД, в этом случае часть работы переходит на интерфейс (т.е. на клиента). Иногда это очень даже оправдано.
Хранят же в БЛОБе картики. И ты же не станешь распихивать отдельные пикселы по таблицам, а потом нормализовать. Ежели те столбцы, которые переменные, составляют некую логически законченную еденицу, то БЛОБ - это абсолютно верное решение.
> чем плохо несоблюдение 1-й н.ф.? хотя бы тем, что в
> select'е нельзя будет использовать "атрибуты", входящие в
> состав BLOB-поля.
А я так понял в задаче Чела этого и нетребуется
> между тем, проблема, которой все испугались, и не проблема
> вовсе, если почитать описание ODBC API. Используя ODBC API,
> можно узнавать программно сколько
> атрибутов на данный момент имеется в данной таблице и
> выполнять те или иные действия в зависимости от их числа,
> при этом и с выборкой из таких таблиц "переменной ширины":)
> тоже никаких проблем не будет. Проблема только в том, что
> ODBC API очень низкоуровневый.
Атрибуты посмотреть можно. Но ему-то вроде как надо хранить переменное кол-во столбцов. Если бы он заранее знал их кол-во, наверное и вопрос-то не задавал.
> PS. возможно, все это можно проделать с использованием OLE
> DB или еще чего, врать не стану. Я юзал только ODBC, а
> давным-давно - MFC CDatabase+CRecordset.
OLE DB - говорят что перспективней, только и всего.
> В любом случае, использование BLOB считаю
> безумием.
Попытка - не пытка.
А еще здесь есть один плюс - можно сделать переменное кол-во столбцов для каждой записи в таблице, если конечно это надо.
|
|
<programming>
|
[C++] Совет нужен по DB 21.05.02 12:25
Автор: PS <PS> Статус: Elderman
|
необходимо создать API для работы с "динамической DB". Т.е. количество полей в таблицах зарание не извесно.
Есть, имхо, два пути:
1. Использовать ALTER TABLE ADD
2. Использовать одно поле BLOB для хранения сериализованых рекордов.
Никаких select по "динамическим" полям делать не надо.
Что лучше ? Есть ли подводные камини при использовании первого метода ?
Предпологается использовать базы: access, oracle, ms sql; возможно foxpro, paradox, my sql.
Пока программный доступ через ado.
|
|
[C++] Совет нужен по DB 21.05.02 12:47
Автор: BILIA Статус: Незарегистрированный пользователь
|
На мой взгляд правильнее использовать 1 ый вариант
> 1. Использовать ALTER TABLE ADD
> 2. Использовать одно поле BLOB
Открытая система проще в разработке и поддержке.
|
| |
[C++] Совет нужен по DB 21.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.
|
| | | | | | | |
Согласен 24.05.02 23:26
Автор: whiletrue <Роман> Статус: Elderman
|
> a SAMYI LUCHIII VARIANT DOBAVIT 3 TABLICY.
> 1- hraint novye fields, 2- types, 3 - values,
> I vse budet normalizovano.
Кстати говоря, я тут поразмыслил мозгами.
Нужно отношение tabl <-> values много ко многим, т.е. нужно завести еще промежуточную таблицу.
А, таблица types - получиться как бы просто информационной (для разбивки values по группам, и может представлять собой вообще даже какое-нибудь дерево... О как).
|
| | | | | | | |
Согласен 24.05.02 09:48
Автор: whiletrue <Роман> Статус: Elderman
|
> a SAMYI LUCHIII VARIANT DOBAVIT 3 TABLICY.
> 1- hraint novye fields, 2- types, 3 - values,
> I vse budet normalizovano.
Все сдаюсь, этот способ действительно рулез.
|
| | | | | | | | |
что-то не догоняю :( 24.05.02 16:49
Автор: 1blin Статус: Незарегистрированный пользователь
|
> > 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 20:56
Автор: + <Mikhail> Статус: Elderman
|
Da hot` varchar. chto problema skonvertirovat`??
> > > 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
|
... опять вернулись к БЛОБу,
Только теперь все нормализовано, и можно атрибут достать Селектом
|
| | | | | | | | | | | |
а ты уверен, что БЛОБ можно использовать в where?:))) 25.05.02 02:25
Автор: йцукенг <jcukeng> Статус: Member
|
|
|
| | | | | | | | | | | | |
Нельзя 25.05.02 17:27
Автор: whiletrue <Роман> Статус: Elderman
|
Ну это уж как задача...
Может этого и не надо...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
