В базе нужно хранить строковые данные в пределах 10к символов. В чем лучше хранить varchar или blob???

Привет, BlackEric!
Вы пишешь 15 февраля 2006:

B> В базе нужно хранить строковые данные в пределах 10к символов.
B> В чем лучше хранить varchar или blob???

Зависит от того, что именно ты собираешься с ними делать.

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

B>> В чем лучше хранить varchar или blob???

AC>Зависит от того, что именно ты собираешься с ними делать.

Данные — просто текст или rtf.Еще не решил, но скорее текст. Задача спускаемая от руководителя к подчиненному.

Делать. Задача поставлена. Получена.Выполнена. Получен отчет. Тоже <10k и эта запись после получения отчета, что эквивалентно закрытию задачи, трогаться будет только в том случае если будут подниматься архивы.
Принцип базы 1 задача — 1 одна запись.
Т.е. все, что относится к задаче лежит в одной записи, кроме списка пользователей.
Он в связанной таблице.

Привет, BlackEric!
Вы пишешь 15 февраля 2006:

B>>> В чем лучше хранить varchar или blob???

AC>> Зависит от того, что именно ты собираешься с ними делать.

B> Данные — просто текст или rtf. Еще не решил, но скорее текст.

Если таки RTF, то VARCHAR не к месту, однозначно.
Судя по тому, что ты описал, я бы для данной задачи
предпочёл таки BLOB.

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:


AC>Если таки RTF, то VARCHAR не к месту, однозначно.
AC>Судя по тому, что ты описал, я бы для данной задачи
AC>предпочёл таки BLOB.

А если текст? Я могу в программе использовать или то или другое. В каком формате лучше делать ввод?
Меня это интересует с точки зрения производительности, ресурсоемкости.

Спасибо за ответы!!!

Привет, BlackEric!
Вы пишешь 15 февраля 2006:

B> А если текст? Я могу в программе использовать или то или другое. В каком формате лучше делать ввод?
B> Меня это интересует с точки зрения производительности, ресурсоемкости.

На таких объемах, существенной разности ты и не заметишь.
Единственное отличие — несколько дополнительных вызовов
функций АПИ для работы с БЛОБами.
Но они имплементированы практически во все средства доступа
и для прикладного программиста "прозрачны".
На "скорости" это никак не скажется.
В плане хранения на сервере, тоже особой разницы не будет,
т.к. "мелкие" БЛОБы не обязательно сидят на спец.страницах.

--
With best regards, Alex Cherednichenko.

Здравствуйте, BlackEric, Вы писали:

BE>Принцип базы 1 задача — 1 одна запись.
BE>Т.е. все, что относится к задаче лежит в одной записи, кроме списка пользователей.
BE>Он в связанной таблице.

Советую все же нормализовать данные, иначе работать с ними будет очень неудобно. А так — что в FB, что в файле на диске — одно и то же. В файле даже удобнее .

AC>На "скорости" это никак не скажется.

Это не совсем так. Будет немножко медленнее.
Критично медленнее или нет — зависит от задачи.

Здравствуйте, Igor Trofimov, Вы писали:

AC>>На "скорости" это никак не скажется.

iT>Это не совсем так. Будет немножко медленнее.
iT>Критично медленнее или нет — зависит от задачи.

Если размер страницы в БД достаточно большой, а блобы — достаточно маленькие, то они могут сидеть на той же странице, что и запись и существенного замедления не будет. Вообще тут речь идет даже не о процентах быстродейтсвия, а о долях процента. С учетом того, что все это будет оборачиваться интерфейсом пользователя и т.п. — эти доли процента вообще превращаются в 0.
Кстати, а если текст по каким либо причинам не влезает в определенные пределы (10К)? В этом плане блоб предпочтительней т.к. более универсален.

Здравствуйте, DarkMaster, Вы писали:


DM>Кстати, а если текст по каким либо причинам не влезает в определенные пределы (10К)? В этом плане блоб предпочтительней т.к. более универсален.

Влезет. 10к это почти 4 листа А4.В софтинке нужно еще будет сделать возможность прикреплять файлы для передачи от юзера к юзеру с сохранением их в БД.

Здравствуйте, BlackEric, Вы писали:

DM>>Кстати, а если текст по каким либо причинам не влезает в определенные пределы (10К)? В этом плане блоб предпочтительней т.к. более универсален.

BE>Влезет. 10к это почти 4 листа А4.

Вот это почти меня и смущает

BE>В софтинке нужно еще будет сделать возможность прикреплять файлы для передачи от юзера к юзеру с сохранением их в БД.

Фигня делов Сохраняешь файл в базе, а потом работаешь только со ссылками (внутренним ID документа). Можешь еще упаковку на лету прикрутить, чтобы база сильно не пухла.
Что-то вроде такой таблицы вырисовывается:
ID — PK
USERID — FK на таблицу пользователей (т.е. владелец документа)
DOCID — FK на таблицу документов/файлов