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

← →
dehkanin (2014-02-19 20:15) [0]

1. Какой тип переменной выбрать для поля записи?
2. Если string то - что указать в поле "size ", чтобы записать текст объёмом свыше 2-х Мб?
Если другой тип - какой?

← →
Anatoly Podgoretsky © (2014-02-19 20:35) [1]

Вообще то это от СУБД зависит

← →
Rouse_ © (2014-02-19 20:42) [2]

2 мега данных в блобе одной записи?!
Да Вы, батенька, эстет :)

← →
dehkanin (2014-02-19 20:46) [3]

СУБД? с использованием языка SQL в данном случае используется приложение Absolute Database.

← →
dehkanin (2014-02-19 20:50) [4]

Rouse: А Вы, "батенька",- острячок?
М.б. не поняли? (Я наверное бестолково объяснил?)
Есть файл rtf объёмом около 2- Мб (текст документа), который надо сохранить в таблице; и таких файлов -много.
Что бы Вы применили?

← →
Inovet © (2014-02-19 21:09) [5]

> [3] dehkanin (19.02.14 20:46)
> с использованием языка SQL в данном случае используется
> приложение Absolute Database.

Три раза перечитал - слова знакомые. А что не FB или MS SQL? Тоже бесплатные. Критерий выбора видимо был какой-то, в т.ч. удобство работы с BLOB, наверное, рассматривалось на первом месте, судя по задаче.

← →
brother © (2014-02-19 21:09) [6]

а ссылки (путь) к файлу не лучше ли хранить?

← →
Inovet © (2014-02-19 21:10) [7]

> [6] brother © (19.02.14 21:09)

Файлы надо расшаривать тогда.

← →
brother © (2014-02-19 21:11) [8]

локал или нет версия не уточнялось...

← →
brother © (2014-02-19 21:12) [9]

> Файлы

папки ли -_-

← →
brother © (2014-02-19 21:13) [10]

да и для нормального сис амина это не проблемма, не известно, кто эти фалй будет отображать или что-то сними делать )))))))

← →
Smile (2014-02-19 21:21) [11]

Пост закончился на ...
Rouse_ © (19.02.14 20:42) [2]
Да Вы, батенька, эстет :)

← →
Inovet © (2014-02-19 21:22) [12]

> [10] brother © (19.02.14 21:13)

Это дополнительные слои для задачи, а так всё средствами базы. Смотря что надо, мы не знаем.

← →
Rouse_ © (2014-02-19 21:42) [13]

> dehkanin (19.02.14 20:50) [4]
> Rouse: А Вы, "батенька",- острячок?

Видимо так и горжусь этим :)
ЗЫ: советую пересмотреть архитектуру хранения, хотя бы на ссылки...

← →
DVM © (2014-02-19 21:47) [14]

> dehkanin (19.02.14 20:15)
> 1. Какой тип переменной выбрать для поля записи?

BLOB поле.

> brother © (19.02.14 21:13) [10]

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

СУБД абсолютно без разницы какого размер данные кладут в ее поле BLOB. Хоть 100 мегабайт, хоть терабайт. Это все будет также файл на диске, но по другому там размещенный. И в случае файла в БД и в случае файла на файловом сервере доступ и к тому и другому будет осуществлять с примерно одной и той же скоростью, ограниченной скоростью TCP соединения.

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

← →
Rouse_ © (2014-02-19 21:57) [15]

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

Угу, было такое заблуждение. На сколько я помню все остановилось на скорости выборки данных при хранении в базе ста фильмов в HD формате.

← →
DVM © (2014-02-19 22:02) [16]

> Rouse_ © (19.02.14 21:57) [15]

> Угу, было такое заблуждение.

Нет тут никакого заблуждения.

> На сколько я помню все остановилось на скорости выборки
> данных при хранении в базе ста фильмов в HD формате.

Причем тут скорость? Кто заставляет выбирать в запросе и вытягивать на клиента BLOB поля содержащие большие объемы данных? Выбирать надо метаинформацию, а по ней тянуть на клиента файл.
Можно подумать копирование на клиента сто фильмов в HD формате быстрая операция.

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

← →
Rouse_ © (2014-02-19 22:05) [17]

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

Скорость бэкапа

← →
DVM © (2014-02-19 22:08) [18]

> Rouse_ © (19.02.14 22:05) [17]

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

← →
Плохиш © (2014-02-19 22:08) [19]

> Критерий выбора видимо был какой-то, в т.ч. удобство работы
> с BLOB, наверное, рассматривалось на первом месте, судя
> по задаче.

Судя по вопросам этих букав в критериях не встречалось ;-)

← →
Rouse_ © (2014-02-19 22:09) [20]

А, ну и до кучи - произвольный доступ к файлу по офсету (дозакачка).

← →
Rouse_ © (2014-02-19 22:09) [21]

> DVM © (19.02.14 22:08) [18]
> Ошибаешься. Бекап средствами СУБД сохраняет только изменения
> от предыдущей версии

Ты сейчас про фаерберд?

← →
Rouse_ © (2014-02-19 22:13) [22]

> DVM © (19.02.14 22:08) [18]
>
> > Rouse_ © (19.02.14 22:05) [17]
>
> Ошибаешься. Бекап средствами СУБД сохраняет только изменения
> от предыдущей версии

Да хотя в принципе пофигу, ты представляешь себе затраты на сохранении изменений в ссылке на данные, и изменении 10 байт с 40 гигабайтном блобе?
Просто тупо время на поиск изменений?

← →
DVM © (2014-02-19 22:14) [23]

> Rouse_ © (19.02.14 22:09) [20]
> А, ну и до кучи - произвольный доступ к файлу по офсету
> (дозакачка).

Опять ошибаешься. Если пользоваться не дельфийскими компонентами доступа, а напрямую вызывая API сервера (хотя может какие компоненты и предоставляют такую возможность, но влюбом случае можно ее реализовать), то возможно произвольное позиционирование в блобе. И докачка по частям и закачка по частям. А если интегрировать свое расширение (dll ) в сервер, так вообще возможности безграничны. В Firebird это есть.

> Rouse_ © (19.02.14 22:09) [21]

> Ты сейчас про фаерберд?

Касательно бекапа в FB не знаю, не делал. В Оракле бекап точно есть Incremental backup.

← →
Rouse_ © (2014-02-19 22:15) [24]

> DVM © (19.02.14 22:14) [23]
> Опять ошибаешься.

С Ораклом не работал - могу и ошибаться.

← →
DVM © (2014-02-19 22:17) [25]

> Rouse_ © (19.02.14 22:13) [22]

> Просто тупо время на поиск изменений?

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

← →
Rouse_ © (2014-02-19 22:19) [26]

Дим, ты не понял.
Дано: таблица с 1 записью с блобом в 40 гигов, и альтернатива - ссылка на данные.
Бэкапим - для того чтоб найти изменения в первом случае, нам нужно перечитать все 40 гигов - нес па?

← →
DVM © (2014-02-19 22:19) [27]

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

В Firebird есть http://www.firebirdsql.org/manual/nbackup-backups.html#nbackup-backups-incr в Oracle есть http://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm

← →
DVM © (2014-02-19 22:23) [28]

> Rouse_ © (19.02.14 22:19) [26]

> Бэкапим - для того чтоб найти изменения в первом случае,
> нам нужно перечитать все 40 гигов - нес па?

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

Но ведь при бэкапе файлов в файловой системе абсолютно такая же картина. Только там вместо страниц кластеры.

← →
Rouse_ © (2014-02-19 22:24) [29]

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

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

← →
DVM © (2014-02-19 22:28) [30]

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

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

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

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

← →
DVM © (2014-02-19 22:33) [31]

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

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

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

← →
Rouse_ © (2014-02-19 22:35) [32]

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

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

← →
DVM © (2014-02-19 23:07) [33]

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

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

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

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

← →
Dennis I. Komarov © (2014-02-20 00:39) [34]

Эмм, Вы еще подеритесь, горячие финские...

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

← →
sniknik © (2014-02-20 08:34) [35]

> этот список, думаю, можно еще продолжить.
этот список можно выкинуть посмотрев на используемый движок -
> Absolute Database
насколько знаю это что-то SQLite, встраиваемый "моно" движок (читал когда-то и про сервер но не видел вопросов о том чтобы его использовать... может его и нету совсем)

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

← →
sniknik © (2014-02-20 08:35) [36]

> что-то SQLite,
что-то типа SQLite,

← →
brother © (2014-02-20 08:45) [37]

я всеж согласен с Розычем, имхо лучше ссылки на файлы...

← →
brother © (2014-02-20 08:48) [38]

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

← →
DVM © (2014-02-20 10:25) [39]

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

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

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

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

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

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

← →
Rouse_ © (2014-02-20 11:40) [40]

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

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

← →
Ega23 © (2014-02-20 12:16) [41]

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

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

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

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

← →
Rouse_ © (2014-02-20 12:17) [42]

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

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

← →
brother © (2014-02-20 12:28) [43]

> неверные ссылки и коллизии между действиями разных пользователей

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

← →
Ega23 © (2014-02-20 12:35) [44]

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

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

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

← →
Jeer © (2014-02-20 15:19) [45]

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

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

← →
brother © (2014-02-20 16:27) [46]

> но делаем по-своему.

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

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

← →
Inovet © (2014-02-20 16:33) [47]

> [46] brother © (20.02.14 16:27)

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

← →
DVM © (2014-02-20 16:37) [48]

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

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

← →
Inovet © (2014-02-20 16:44) [49]

> [48] DVM © (20.02.14 16:37)
> Зачем делать протокол

Раз 1 и 2 варианты не устраивают по каким-то причинам.

← →
Ega23 © (2014-02-20 16:48) [50]

> Расчетливые практики давно это поняли

Это всё хорошо работает только в том случае, когда вся эта байда стоит где-то далеко и пытливые ручки пользователей, а также пытливые ручки наполняльщиков БД не могут дотянуться до этих файлов.
И опять-таки невозможность snapshot-транзакции.

← →
Ega23 © (2014-02-20 16:50) [51]

> Раз 1 и 2 варианты не устраивают по каким-то причинам.

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

← →
Rouse_ © (2014-02-20 16:54) [52]

> Ega23 © (20.02.14 16:50) [51]
> Практика показывает, что в 99% случаев хранение блобов вне
> СУБД - это либо неправильный выбор самой СУБД, либо блажь
> в стиле "да я всегда так делал и всё работало".

Хочешь я на тебя задачу по серваку перекину завтра? :)
Чиста для поржать через месяц, когда ты будешь говорить все с точностью наоборот? :)

← →
Ega23 © (2014-02-20 16:57) [53]

Когда-то давным давно, когда пни ещё были 133-ми, винты - гигабайтными, а винда - 95-й и стояла параллельно с DOS-ом, понадобилось моему бате под DOS-ом место на диске C. А места-то и не было. Посмотрев, чё каг, он обнаружил огромный файл на 40 метров с расширением swp. И удалил его к лешему. И записал на освободившееся место то, что было нужно.
А потом матерился и говорил что-то про масдай, который ваще негрузицо.

Такая вот история. Это к вопросу ссылочной целостности.

← →
Rouse_ © (2014-02-20 16:59) [54]

> Ega23 © (20.02.14 16:50) [51]
> Практика показывает, что в 99% случаев хранение блобов вне
> СУБД - это либо неправильный выбор самой СУБД, либо блажь
> в стиле

Кстати Легыч, до кучи - знаешь почему у нас багтрекер три дня лежал, да и щас ворочается едва? Все из-за того что ELF аттачи (сами по себе махонькие по 100 кб в среднем) сидят в базе. Жека эксперементировал с этим делом и щас тож думает как их оттуда выцарапать, чтоб базенка не проседала на 200 тыщах дубликатов.

← →
Ega23 © (2014-02-20 17:00) [55]

> Чиста для поржать через месяц, когда ты будешь говорить
> все с точностью наоборот? :)

Ты внимательно [50] прочитал? Не ты ли столько раз говорил про какую-нить бабку, которая сносит userdb потому что "а нафиг оно нужно?".

← →
Ega23 © (2014-02-20 17:02) [56]

> Кстати Легыч, до кучи - знаешь почему у нас багтрекер три
> дня лежал, да и щас ворочается едва? Все из-за того что
> ELF аттачи (сами по себе махонькие по 100 кб в среднем)
> сидят в базе. Жека эксперементировал с этим делом и щас
> тож думает как их оттуда выцарапать, чтоб базенка не проседала
> на 200 тыщах дубликатов.

Так может проблема не в хранении их "где-то-там", а в выборе СУБД и железа под конкретную задачу?

← →
Rouse_ © (2014-02-20 17:03) [57]

> Ega23 © (20.02.14 17:00) [55]
> Ты внимательно [50] прочитал? Не ты ли столько раз говорил
> про какую-нить бабку, которая сносит userdb потому что "а
> нафиг оно нужно?".

Прочитал и че? У нас сервер ГС от пятерки который хранит данные в куче поддерживаемых форматов баз, как фаерберд, MSSQL, так и ораклы всякие и че там еще впихнуть можно.
Угадай, сколько тикетов в багтрекере из-за того что базы убитые стали?
А как думаешь кто убил? А воть такие-же специалисты, которые SWP файл грохают, а потом матерятся и задают вопросы о ссылочной целостности :))))

← →
DVM © (2014-02-20 17:06) [58]

> Rouse_ © (20.02.14 16:59) [54]

> Все из-за того что ELF аттачи (сами по себе махонькие по
> 100 кб в среднем) сидят в базе.

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

← →
Rouse_ © (2014-02-20 17:08) [59]

> DVM © (20.02.14 17:06) [58]
> Все из-за неправильного запроса где нибудь.

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

← →
Ega23 © (2014-02-20 17:13) [60]

> А как думаешь кто убил? А воть такие-же специалисты, которые
> SWP файл грохают, а потом матерятся и задают вопросы о ссылочной
> целостности :))))

Представь себе на секундочку, что наш ImageList на 300 с лишним иконок сидит не в датамодуле, а каждая иконка лежит рядом с exe-шником отдельным файлом.
Сколько в течении недели позвонят в суппорт с претензией "у меня иконки слетели, программа не работает"?

← →
sniknik © (2014-02-20 17:17) [61]

> где нибудь явно или косвенно вытянуть в запросе.
запросы с * используют например... и тянутся не нужные "файлы" на клиента.

← →
Rouse_ © (2014-02-20 17:18) [62]

> Ega23 © (20.02.14 17:13) [60]

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

← →
Ega23 © (2014-02-20 17:38) [63]

> представь что они сидят в базе - вопрос будет такой-же.

А как ты в базу просто так залезешь?

← →
Rouse_ © (2014-02-20 18:02) [64]

> Ega23 © (20.02.14 17:38) [63]
> А как ты в базу просто так залезешь?

А она перестала быть файлом на диске?

← →
dehkanin (2014-02-20 18:12) [65]

Ни фига себе чего Вы понаписали!
Я правильно понял, что лучше хранить в blob?
В принципе я так и делал, но кто-то меня раскритиковал и я засумлевался.
А string, WideString, AnsiString, Memo?

← →
Rouse_ © (2014-02-20 18:17) [66]

> dehkanin (20.02.14 18:12) [65]
> Ни фига себе чего Вы понаписали!
> Я правильно понял, что лучше хранить в blob?

Мнения скажем так, разделились.
Часть апологетов за блоб, а остальные за хранение во внешнем файле :)

← →
clickmaker © (2014-02-20 18:28) [67]

> А string, WideString, AnsiString

а с ними-то какие сложности?

← →
dehkanin (2014-02-20 18:37) [68]

А разве они потянут объем 2 мб?
Кажется не получится.

← →
dehkanin (2014-02-20 18:38) [69]

Имея ввиду хранение в таблице?

← →
clickmaker © (2014-02-20 18:39) [70]

> А разве они потянут объем 2 мб?

почему не потянут? строка на 32-бит системе может быть до 2 гигов

← →
dehkanin (2014-02-20 18:41) [71]

А как это можно сделать? Применительно к таблице?

← →
dehkanin (2014-02-20 18:42) [72]

Я -не представляю как!

← →
dehkanin (2014-02-20 18:44) [73]

Вот есть, например, файл .rtf около 2 мб.
Как его записать в строкой, как Вы говорите и впихнуть в таблицу?

← →
Inovet © (2014-02-20 18:48) [74]

> [73] dehkanin (20.02.14 18:44)

Ты про таблицу здесь не спрашивал, ты спросил про типы в Делфи

> [65] dehkanin (20.02.14 18:12)
> А string, WideString, AnsiString, Memo?

← →
clickmaker © (2014-02-20 18:49) [75]

> и впихнуть в таблицу?

в поле типа Blob или как оно там называется в Absolute Database, какие проблемы?

← →
Ega23 © (2014-02-20 19:22) [76]

> А она перестала быть файлом на диске?

Да, но это 1 файл. А не 100500 маленьких.
Лан, завтра за стаканом поспорим :))

← →
Rouse_ © (2014-02-20 19:24) [77]

> Ega23 © (20.02.14 19:22) [76]
> Лан, завтра за стаканом поспорим :))

Приходи с деньгами, я люблю дорогой коньяк :)

← →
Ega23 © (2014-02-20 19:38) [78]

Да-да. И Дима сидит с Gtool и 30 тыщ файлов в блобах. И материалов ещё 200 тыщ. А в базе - ссылки.

← →
Rouse_ © (2014-02-20 19:43) [79]

> Ega23 © (20.02.14 19:38) [78]
> Да-да. И Дима сидит с Gtool и 30 тыщ файлов в блобах. И
> материалов ещё 200 тыщ. А в базе - ссылки.

Кстати об этом...
Тебе не кажется что только запуск вот этой всей штуки, которой ты перечислил и сам реализовал, у Димы занимает около пяти-семи минут? :)

← →
Rouse_ © (2014-02-20 19:44) [80]

> Тебе не кажется

Блин, * Тебе не кажется - что это слишком дохрена времени? :)

← →
Rouse_ © (2014-02-20 19:45) [81]

Ну а уж отзывчивость интерфейса с полуминутными замерзаниями - тож доставляет :)

← →
Ega23 © (2014-02-20 20:05) [82]

> Тебе не кажется что только запуск вот этой всей штуки, которой
> ты перечислил и сам реализовал, у Димы занимает около пяти-
> семи минут? :)

У Димы запуск GTool3 занимает 3-5 секунд против полутора минут GTool2, чем он страшно доволен.

← →
Ega23 © (2014-02-20 20:08) [83]

> Ну а уж отзывчивость интерфейса с полуминутными замерзаниями
> - тож доставляет :)

Замерзания там на формировании обновлений и на синхронизации с ликсервером.

Хотя нет, есть там один режим, галочку поставить надо. Когда показывается только то, что не включено в обновления. Там да, секундные залипания есть.

← →
Rouse_ © (2014-02-20 20:43) [84]

> Ega23 © (20.02.14 20:05) [82]
> У Димы запуск GTool3 занимает 3-5 секунд

Не верю.
Если завтра ты при мне запустишь свою "байду" на его компе за 5 (фиг с ним - 10) секунд на моих глазах - я ставлю ящик коньяка.

← →
Rouse_ © (2014-02-20 20:45) [85]

> Rouse_ © (20.02.14 20:43) [84]

А если не запустишь... давно не был в Дисней-ленде :)))

← →
Rouse_ © (2014-02-20 20:54) [86]

Но спор делаем честный, т.е. ребут с нуля и запуск твоей системы :)
Я даю прогноз - 4 минуты на инициализацию, задержка до 12 секуннд на каждой операции добавления/изменения :)

← →
Ega23 © (2014-02-20 21:00) [87]

Подключился к своей машине, запустил из-под отладчика. Запуск мгновенный. База сетевая, не локальная. Рабочая или нет - я тебе сейчас не могу ответить, но с вероятностью 99% - ровно та же, которую использует Дима.
Непосредственно на Диминой машине посмотрим завтра.
Ящик коньяка оставь себе, я не играю в азартные игры. Но кто из нас окажется неправ - тот завтра пишет в этой ветке опровержение своим словам. :)

← →
Ega23 © (2014-02-20 21:02) [88]

> задержка до 12 секуннд на каждой операции добавления/изменения :)

Ээээ... Вот этот момент поясни, пожалуйста.
Добавление-изменение чего именно?

← →
Ega23 © (2014-02-20 21:21) [89]

> Рабочая или нет - я тебе сейчас не могу ответить, но с вероятностью
> 99% - ровно та же, которую использует Дима.

Полистал "байду". Судя по датам изменений - база боевая.

Просто технически, с чего должна тормозить база при наличии в ней 100500 файлов по 100500 мегабайт? Чем хранение этих файлов в базе отличается от хранения их же рядом с ней, ну кроме дополнительных неудобств во втором случае. Следуя упомянутым выше теориям, в базе должно быть быстрее, на практике что-то там может замедлять, но не в отношении 10минут/10 секунд. Значит в базе что-то не так сделано.

Это только мои умозаключения, неподкреплённые практикой.

Спакуха. Через пару часов отпишемся, кто там в чём виноват :)

ждемс...

> Просто технически, с чего должна тормозить база при наличии
> в ней 100500 файлов по 100500 мегабайт?

Да вот мне тоже непонятно, почему этого многие не понимают?

> [90]
> Просто технически, с чего должна тормозить база при наличии
> в ней 100500 файлов по 100500 мегабайт?

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

> выкачать блоб целиком, прочитать байт

Это зависит исключительно от СУБД.

← →
Кщд (2014-02-21 10:42) [96]

>RWolf © (21.02.14 10:27) [94]
>Чтение одного байта из середины файла в БД: выкачать блоб целиком, прочитать байт.
выкачивать BLOB целиком никто не запрещает
кто так не хочет поступать, читает этот байт на сервере и возвращает клиенту

> Это зависит исключительно от СУБД.

так о чем и речь!

> так о чем и речь!
>

Речь о том, что СУБД надо под задачу выбирать.

> [94] RWolf © (21.02.14 10:27)
> выкачать блоб целиком, прочитать байт

Какие тупые разработчики СУБД, не понимают таких простых вещей.

← →
Styx (2014-02-21 12:17) [100]

> Просто технически, с чего должна тормозить база

Я тоже так рассуждал. Но...
Сферическая база в вакууме не быстрее и не медленнее сферической ФС, которая тоже суть база данных.
А вот два конкретных воплощения того и иного подхода нужно сравнивать на тестах. У меня получилось быстрее НЕ писать в BLOBы.

> У меня получилось быстрее НЕ писать в BLOBы.

А с этим никто и не спорит. Если есть возможность записи напрямую, то это полюбасу будет быстрее, чем запись через дополнительные прослойки.
Речь не за скорость шла.

> [100] Styx (21.02.14 12:17)
> У меня получилось быстрее НЕ писать в BLOBы.

Интересно - на много ли?

вот в ms sql 2008 есть такая штука: Хранилище FILESTREAM объединяет компонент SQL Server Database Engine с файловой системой NTFS, размещая данные больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе в виде файлов.
Но здесь профит по скорости можно получить, размещая этот файлстрим в другом разделе, а лучше вообще на другом физическом диске.

← →
Styx (2014-02-21 13:37) [104]

> Интересно - на много ли?

Намного. Но это был MySQL и PHP, а в случае файлов - голый Apache.

С глубоким прискорбием приходится признать что да - Лежка, программист :)
Ему таки удалось разогнать старую корявую утилитку, которая только запускалась три минуты (правда на убитом компе) до вполне таки приличных значений :)
Но коньяк он у меня не получит, раз спорить не стал :)))

> Намного. Но это был MySQL и PHP, а в случае файлов - голый
> Apache.

Ну так это немножко другое. Когда у тебя уже система с кучей скриптов и картинок во внешних файлах, то присобачить туда "ещё какое-то количество" - тут вроде и ничего такого особенного не будет.
А если учитывать то, что в DBISAM, по слухам, вторичных ключей нет, то вся ссылочная целостность вообще по одному месту идёт.

> Но коньяк он у меня не получит, раз спорить не стал

Я не играю в азартные игры.
А коньяк - через час попьём. :)

> Styx (21.02.14 13:37) [104]
>
> > Интересно - на много ли?
>
> Намного. Но это был MySQL и PHP

Вот из-за MySQL такое суеверие против хранения файлов в БД и появилось.
Точнее даже не из-за самого MySQL, а места, где он чаще используется - веб программирования. Там, да, не очень принято хранить файлы в БД, и тянуть их и без того тормозным PHP, когда вместо этого можно отдать как статику через Apache или NGNIX

> [105] Rouse_ © (21.02.14 13:56)
> С глубоким прискорбием приходится признать что да - Лежка, программист :)

А что с прискорбием? целый ящик коньяка у тебя остался, да и Лежка не зря харч ест.

> Точнее даже не из-за самого MySQL, а места, где он чаще
> используется - веб программирования.

+ очень многа.

> Но коньяк он у меня не получит, раз спорить не стал :)))

Так ему и надо

> А коньяк - через час попьём. :)

Как пиво, так пожалуйста хоть в четверг.
Как коньяк, так пожалуйста хоть в пятницу.
Как концерт, так нееее. День не подходит.
)))

> Германн © (21.02.14 16:50) [112]
> Как концерт, так нееее. День не подходит.

А нафига?
Мне проще Евгения будет послушать где-нить так числа седьмого марта прямо в офисе... Переться еще куда-то :))))

> [114] clickmaker © (21.02.14 17:07)

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

> [115] Inovet © (21.02.14 17:13)

а, ну Розыч наверно предложил: "Евгений, а не мог бы ты нам сбацать пару-тройку вещей за ящик коньяка? А то Легыч все равно не берет да и петь не хочет"

← →
dehkanin (2014-02-21 18:55) [117]

Ребяты!
Вы чего-т там о своём? О "девичьем"?
А у меня между тем очередное "горе"
Гружу документ rtf в RichEdit: abcRichEdit1.Lines.LoadFromFile("000005.rtf");
А он, г-г-а-а-д-ддд открывает вот так:

{\rtf1\fbidis\ansicpg1251{\info{\title "Гражданский кодекс Российской Федерации (часть первая)" от 30.11.1994 N 51-ФЗ
(ред. от 02.11.2013)}
{\author ConsultantPlus}
}
{\fonttbl
\f202\fcharset204\froman\fprq2 Arial;
\f200\fcharset204\fmodern\fprq1 Courier New;
\f201\fcharset204\froman\fprq2 Arial;
\f400\fcharset204\froman\fprq2 Tahoma;
}
......... и т.д.
Где текст документа, а где знаки.
Между тем в MSOffice естественно читается нормально.
Как привести его (RichEdit) в "чувство"? Чтобы он ненужные знаки не высвечивал?
Кодировка? Если -да, то как?

← →
dehkanin (2014-02-21 19:50) [118]

Дополню ещё что при открытии документа на 1-2 сек текст сначала высвечивается нормально, а потом -вот такая ерунда.

TRichEdit.PlainText

← →
dehkanin (2014-02-21 21:21) [120]

Если это совет так снизойдите и объясните поподробнее.
Вставка этой строки перед загрузкой файла ни к чему не привела.

> [120] dehkanin (21.02.14 21:21)
> Если это совет так снизойдите и объясните поподробнее.

Дано: я за 10 секунд открыл хелп, за 30 прочитал, за 2 минуты ответил здесь. Найти: сколько времени я буду это здесь пересказывать.

Controls whether the rich edit control treats the text as plain text or rich text when streaming to or from a file.

To write the rich text in the control to a plain text file, set PlainText to true before streaming the text to a file. To ignore the rich text information encoded in a file, set PlainText to true before streaming the text to the control. To stream in the rich text attributes encoded in a file, or save the encoding of the rich text attributes to a file, set PlainText to false.

If the rich text attributes of a file are encoded in some format other than rich text format (RTF), it is necessary to use a converter on the text, even when PlainText is true.

Note: Rich edit controls do not directly support streaming. Use the Lines property to stream to or from a file.

← →
dehkanin (2014-02-21 22:33) [122]

Ну наверное надо ещё и знать что искать?
=============
Управляет рассматривает ли контролер RichEdit текст как простой или текст rich когда направляется в файл или извлекается из него.
Чтобы записать текст rich в виде простого текстового файла, установите PlainText в true перед направлением текста в файл. Чтобы игнорировать информацию rich теста, закодированную в файле, установите Plain Text в true перед направлением текста на контролер. Чтобы направить кодированные атрибуты текста rich в файл или сохранить кодирование атрибуты кодирования в файл, установите Plain Text в false.
Если атрибуты текста rich файла кодированы в формате в некоторых других форматах отличающихся от RTF, необходимо использовать конвертер, даже когда Plain Text -true.
Примечание: Контролеры Rich Edit не поддерживают напрямую поток. Используйте свойство Lines чтобы направить в файл или извлечь из файла.
==============
Мне проще прочитать чем понять :)

А, все же, понять придется, иначе - в дворники.

← →
ухты (2014-02-21 22:48) [124]

> и тянуть их и без того тормозным PHP
дело не в пхп и не в его тормознутости, а в том что картинки в кэш должны лететь, а когда /гетинадж?ид=12345 то не летит...

> ухты (21.02.14 22:48) [124]
>

> а когда /гетинадж?ид=12345 то не летит...

Это почему это в кэш не попадет, попадет еще как. Если вот этот 12345 для одной и той же картинки не меняется, проблем с кэшем то нет.

> dehkanin (21.02.14 21:21) [120]
>
> Если это совет так снизойдите и объясните поподробнее.
> Вставка этой строки перед загрузкой файла ни к чему не привела.
>

Это именно совет про что читать справку. Вставлять советы в код не рекомендую вообще никогда

> Rouse_ © (21.02.14 16:56) [113]
>
>
> > Германн © (21.02.14 16:50) [112]
> > Как концерт, так нееее. День не подходит.
>
> А нафига?
> Мне проще Евгения будет послушать где-нить так числа седьмого
> марта прямо в офисе... Переться еще куда-то :))))

Если я правильно понял топик Юрия, то твой смайлик слегка неуместен.
Или вы в состоянии предложить более достойный ангажемент?

> [122] dehkanin (21.02.14 22:33)
> Мне проще прочитать чем понять :)

Это ответ? Ответ неверный пользоваться ГуглПереводчиком неравно пересказать. Верный ответ: ты сам мог выполнить все указанные пункты, + сделать что там в справке описано, а если неполучилось/непонятно - спросить уже более осознанно.

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