Как лучьше реализовать следующее

← →
Cranium © (2003-04-14 17:28) [0]

Есть таблица - каталог товара... Стандартно
1) ID товара
2) наименование
3) цена
4) и т.д.
Кроме этого есть поля типа BLOB, в котрых содержаться изображения товара, rtf документы с описанием, ну возможно еще что-то...
Так вто вопрос в следующем, что лучьше хранит все поля типа BLOB в отдельной базе и подгружать их по доп запросу, или хранить в основной базе в выше упомянутой таблицы....
Сервер планируется Yaffil, количестово записей в таблице порядка 20 тысяч, это уже то что сейчас наскребется, думаю через год работы увеличится на 30% ....

← →
kravchuk © (2003-04-14 17:52) [1]

Думаю нормально хранить в той же таблице, физически в записи БД хранится указатель на BLOB.

← →
Cranium © (2003-04-14 17:55) [2]

Думаешь размер BLOB, не зкажется на скорости запроса к таблице, как ни как каталог товаров, часто обращаться будут....

← →
kravchuk © (2003-04-14 18:17) [3]

думаю что не скажется, я говорил, что физически хранится только указатель, т.е. на скорость запроса не скажется, то же самое что ты добавишь еще одно целочисленное поле.

← →
Vassiliy © (2003-04-15 08:54) [4]

На скорость выполнения запроса поле BLOB скажется, если Вы, конечно, это поле запросом выбираете, причем существенно.

← →
alexb (2003-04-15 09:29) [5]

В любом случае, если есть возможность отказаться от BLOB - отказываюсь. Все все равно Вы не реализуете (редактирование графики, rtf). Это первое. Второе - надежность. Третье - простота.
Если все таки применяете BLOB, то лучше в своей БД. Количество записей у Вас не такое большое.

← →
Johnmen © (2003-04-15 09:39) [6]

>...все равно Вы не реализуете ... Это первое

На основании чего ты так плохо думаешь об авторе вопроса ?

>Второе - надежность...

Надежность чего ?

>Третье - простота

Простота чего ?

>Если все таки применяете BLOB, то лучше в своей БД.

Извини, бред...

← →
alexb (2003-04-15 10:00) [7]

Мы имеем в BLOB и текст и графику. Кол-во записей > 200 000. Если требуется изменить рисунок, а для типографии у него расширений очень много, то подставляем необходимый кусок программы и только для просмотра (конечно + замена).
Вопрос, насколько увеличиться программа для одного такого куска?
Надежность. Только один раз БД у нас сбойнула. Все текстовые строки сместились. Честное слово не знаю почему так получилось. Но редактирование у нас заняло много времени. Кроме того, поинтересуйтесь, когда справочные системы применяют BLOB?
Простота. Есть ли необходимость забивать строки в BLOB? Если мне требуется документ, шаблон документа и не только в rtf, да, я его помещаю, но опять же, никогда в БД не редактирую. Зачем отнимать у себя время?

← →
alexb (2003-04-15 10:15) [8]

Johnmen!
Извини, еще добавлю. Что я должен думать об авторе? Прочти внимательно его вопрос, хотя бы ошибки.
И на счет "в отдельной БД". Это тоже в вопросе.
Извини за "бред".

← →
Cranium © (2003-04-15 13:29) [9]

> И на счет "в отдельной БД". Это тоже в вопросе.
> Извини за "бред".

Чем же это бред? Две базы (два файла). В одной базе все что касается склада и торговля, во второй чисто каталог документации на товар.... В клиентском приложении, коннект к двум базам(файлам), в случае продажи запрос толко к складской базе, при необходимости получить техническую документацию на товар к другой запрос к другой базе... Что тут бредового? Если есть выигрышь в производительности есть резонность в такой схеме, если нет, то пусть все лежит в одной базе.....\
Или у автора выше упомянутых строк другое понятие о термине БД?:)))))

← →
Johnmen © (2003-04-15 14:03) [10]

Выигрышь в производительности - это что ? Конкретно на чем он будет обеспечиваться ?
>Что тут бредового?
Ну что я могу сказать...? Попробуй... И поймешь...:)))

← →
kravchuk © (2003-04-15 15:23) [11]

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

Что касается 2 баз - все не так уж запущено. Вот пример из одной реально существующей СУБД.
Есть "деловая" БД (обычный "реквизитный" формат полей) и "мультимедийная", состоящая из видеороликов, графики и отсканированных документов. Так вот вторая хранится в "отдельной" упаковке в спец.каталоге в виде ОБЫЧНЫХ ФАЙЛОВ соотв.типа (как правило, не подлежащих редактированию - есть спец. группа людей и спец.средства для заведения и обновления всей этой байды. Они после коррекций пишут все это в БД не чаще одного раза в неделю).
В основной БД лежат только ссылки (пути и типы файлов), с помощью которых могут "поднять" мультимедию нужного объекта БД.
Сама БД имеет размер около 200 мб, а мультимедия - более 60 Гб гигов (кусками на рейде или компактах). Раз в неделю (обычно ночью) обновление идет порядка 10-15 часов, зато при работе узеров база "летает".

Ни в коей мере не хочу оспаривать мнение высказавшихся тут, но против категорических заявлений типа "бреда" и т.д.
Никто и ничто так эффективно не делает из человека дурака как собственная самоуверенность.

Уверенность, подкрепленная знаниями и опытом, позволяет утверждать (а не заявлять !), что в данной постановке вопроса, наличие более одной БД есть типа "бред". :)))
Но против категорических заявлений типа "бреда" и т.д. :)

← →
alexb (2003-04-15 16:54) [14]

Мужики! Что мы спорим?
Я бы делал для этого конкретного случая одну БД. Но это мое мнение. Пусть автор поступает как считает нужным.

Ну бывавает, что хранят в отдельной таблице, а вот в отдельной базе, это что то. При это это связанная один к одному информация. Связь один к одному не эффективна, по сранению с хранением этих полей в одной таблице, кроме прочего она не удовлятворяет первому уровню правил нормализации. А разделение баз, вообще не будет удовлетворять никакому уровню.

Кто-нибудь видел содержимое эмпэтришного сидюка ? Там что, все нормализовано и запхано в одну нормализованную БД-файл ? А поди ж ты, и лирика, и клипы, и графика, и музон. Это я к тому, что нельзя не видючи больного класть его на операцию только со слов родственников

Как лучьше реализовать следующее Найти похожие ветки