Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как записать в таблицу БД текст объёмом свыше 2-х мегабайт?

Страницы: < 1 2 3 4 5 6 7 >
dehkanin © (2014-02-19 20:15:00)
1. Какой тип переменной выбрать для поля записи?
2. Если string то - что указать в поле "size ", чтобы записать текст объёмом свыше 2-х Мб?
Если другой тип - какой?

DVM (2014-02-20 16:37:00) [81]

> Например, можно файлы не расшаривать, сделать свой протокол
> передачи, нужных кусков в обоих направлениях с учётом специфики.
>

Зачем делать протокол, если он уже сделан в сервере СУБД?
Сначала мы будем делать протокол, потом мы будем пытаться разрулить одновременный доступ, потом мы будем заниматься синхронизацией файловой системы с базой, потом...

Inovet (2014-02-20 16:33:00) [82]
> [46] brother © (20.02.14 16:27)

Например, можно файлы не расшаривать, сделать свой протокол передачи, нужных кусков в обоих направлениях с учётом специфики.

brother (2014-02-20 16:27:00) [83]
> но делаем по-своему.

О_о это как? ведь только 2 варианта:

> файлы vs blob-поля

Jeer (2014-02-20 15:19:00) [84]
>Перешли на хранение файлов вне базы именно из-за тормозов.

Расчетливые практики давно это поняли и предоставили поле битвы "файлы vs blob-поля" теоретикам, которым тоже надо кушать и которые хотят, чтобы их слушали.
Слушаем, но делаем по-своему.

Ega23 (2014-02-20 12:35:00) [85]

> еще раз - read only
> коллизии - обращение нескольких пользователей к одному файлу?

рид-онли - это небольшой частный случай.

Фактически, храня файлы вне СУБД, часто приходится изобретать велосипед по реализации поверх них СУБД-шного функционала. Который в СУБД уже реализован.

brother (2014-02-20 12:28:00) [86]
> неверные ссылки и коллизии между действиями разных пользователей

еще раз - read only
коллизии - обращение нескольких пользователей к одному файлу? если да - не вижу проблемм...

Rouse_ (2014-02-20 12:17:00) [87]

> Ты уверен, что именно из-за них?

Угу, можешь у Жеки уточнить в понедельник, он более подробно расскажет.

Ega23 (2014-02-20 12:16:00) [88]

> Перешли на хранение файлов вне базы именно из-за тормозов.

Ты уверен, что именно из-за них?

По теме:
В хранении файлов вне СУБД есть только один плюс: скорость полного бэкапа. Дифференцированный бэкап, ЕМНИП, есть не у каждой СУБД.
В остальном это плохо из-за:
1. Отсутствия ссылочной целостности.
2. Отсутствии в разграничении прав доступа.

Практика хранения блобов вне СУБД - чисто историческое явление. Ну когда там всякие ограничения на размер самой БД были. А, ещё поколение MySQL-щиков тоже тут постаралось.

Rouse_ (2014-02-20 11:40:00) [89]

> Ты изменил бы свое мнение, когда столкнулся бы с системой,
> хранящей миллионы файлов и с которой постоянной работает
> хотя бы десяток человек.

У нас развернута такая система, с ней работает пара сотен тысяч человек, а не десятков. Это собственно сервер обновлений, в котором ежедневно меняется 7-10 файлов размером от 10 до 60 мегов каждый, а всего файлов в районе 900 с копейками + ежемесячно по 10-15 новых добавляется).
Перешли на хранение файлов вне базы именно из-за тормозов.

DVM (2014-02-20 10:25:00) [90]

> brother © (20.02.14 08:48) [38]

> да и для бэкапа базы это лучше, если единожды врайт ссылку
> и далее реад онли...

Нет никакой разницы. База бекапится тоже не вся целиком. Ничто не изменилось - ничего и не забекапится.

> brother © (20.02.14 08:45) [37]
> я всеж согласен с Розычем, имхо лучше ссылки на файлы...
>

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

Этот вариант жизнеспособен, если действительно база только для чтения или для использования в "одно рыло".

brother (2014-02-20 08:48:00) [91]
да и для бэкапа базы это лучше, если единожды врайт ссылку и далее реад онли...

brother (2014-02-20 08:45:00) [92]
я всеж согласен с Розычем, имхо лучше ссылки на файлы...

sniknik (2014-02-20 08:35:00) [93]
> что-то SQLite,
что-то типа SQLite,

sniknik (2014-02-20 08:34:00) [94]
> этот список, думаю, можно еще продолжить.
этот список можно выкинуть посмотрев на используемый движок -
> Absolute Database
насколько знаю это что-то SQLite, встраиваемый "моно" движок (читал когда-то и про сервер но не видел вопросов о том чтобы его использовать... может его и нету совсем)

т.е. используется локально, "в одно рыло", (с вероятностью 95%)... цель хранения в базе скорее всего вовсе не в "высоких материях", а попросту - лишить юзера работать с файлами в чем то помимо проги.
из написанного списка только 6 как то имеет смысл для условий топиккастера (может иметь если он делает что-то этого требующее... ставлю на вероятность этого менее 3% :)).

Dennis I. Komarov (2014-02-20 00:39:00) [95]
Эмм, Вы еще подеритесь, горячие финские...

У ТС поди все в 1NF, а Вы тут о высоком...

DVM (2014-02-19 23:07:00) [96]
Конечно, оба подхода к хранению несомненно имеют право на жизнь. И надо очень тщательно изучить все нюансы задачи прежде чем принимать решение о хранении файлов в БД или на диске.

Хранение в базе - более общий случай, в файлах - частный. Более общий как следствие более гибкий, но вероятно немного более медленный вариант.

Плюсы хранения в БД такие:
1) Более удобное разграничение доступа к файлам.
2) Одновременный доступ к файлам множества пользователей, в том числе на запись.
3) Автоматическая поддержка целостности базы без необходимости синхронизации изменений в файловой системе и базе.
4) Более простой удаленный доступ, нет необходимости организовывать доп удаленный доступ к файлам, опять же с разрешениями на запись отсутствуют сложности. Достаточно открыть один порт.
5) Более простой бэкап без остановки базы.
6) Нет проблем с одинаковыми именами файлов, может хранится множество версий одного и того же файла.
7) Нет проблем с ограничениями некоторых файловых систем на количество файлов в папке.

этот список, думаю, можно еще продолжить.

Rouse_ (2014-02-19 22:35:00) [97]

> Как думаешь, что будет быстрее - бэкап миллиона файлов лежащих
> отдельно на диске или бэкап одного файла БД, где лежит тот
> же миллион?

Зависит от подхода. Если делать правильно - скорость будет примерно одинаковая (чуть медленней при миллионе, но не значительно).
Если по классике, обходом каталога - в разы медленней.

DVM (2014-02-19 22:33:00) [98]

> Rouse_ © (19.02.14 22:24) [29]
>

Будет время может и потестирую. Мне честно говоря не хочется. Это целый день же займет с большими объемами.

Одно могу сказать, чтение из СУБД большого файла и запись в СУБД большого файла не сильно отличается от скачивания оного или загрузки через HTTP например. Это я проверял.

DVM (2014-02-19 22:28:00) [99]

> Rouse_ © (19.02.14 22:24) [29]

> Давай просто протестируй.

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

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

Rouse_ (2014-02-19 22:24:00) [100]

> DVM © (19.02.14 22:19) [27]

Давай просто протестируй.
Возьми Аватара в HD (60 гигов) и залей в таблицу.
Сделай бэкап, замерь время.
Произвольно измени в блобе данные (байт 100), сделай бэкап - замерь время.
Напиши код который последовательно читает данные с диска и из базы - замерь время.

Страницы: < 1 2 3 4 5 6 7 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »