Здравствуйте, criosray, Вы писали:
E__>>Самое забавное, что похоже, именно так и есть(гугл поможет найти еще подтверждения). Для меня, кстати, это новость(я как-то не задумывался раньше, в чем гугл хранит видео), я и сам удивился.
C>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.
Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.
E__>>>Самое забавное, что похоже, именно так и есть(гугл поможет найти еще подтверждения). Для меня, кстати, это новость(я как-то не задумывался раньше, в чем гугл хранит видео), я и сам удивился.
C>>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.
___>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.
Хранить большое количество бинарной информации в таблицах БД? Удачи.
Здравствуйте, criosray, Вы писали:
C>>>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.
___>>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.
C>Хранить большое количество бинарной информации в таблицах БД? Удачи.
Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
Здравствуйте, criosray, Вы писали:
C>>>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.
___>>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.
C>Хранить большое количество бинарной информации в таблицах БД? Удачи.
Нет, хранение бинарной информации больших объемов в БД совершенно неприемлимо. Мы говорим о терабайтах информации. Информации, которую не возможно практически кешировать (точнее возможно, но в ограниченном объеме). Нагрузка на базу будет колоссальной и совершенно неприемлимой.
Здравствуйте, hattab, Вы писали:
C>>Хранить большое количество бинарной информации в таблицах БД? Удачи.
H>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?
Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?
C>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.
H>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
___>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?
___>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?
По той ссылке, кстати, написано то, о чем я говорю:
1. First of all consider the cost of serializing the document/image into the blob.
2. Second think about timeouts and broken streams when retreiving larger datas that aren't quite one shot.
3. Third, your larger files will go from d/b to web server as 4 kb chunks and each chunk will require handshaking — too much overhead — you decide.
4. Fourth, What really guarantees that you will never run across an image > 50KB or document > 1 MB
5. Fifth, Sql server is gonna break the image/document up so it fits inside it's small small pages, and obviously it'll have to peice it together in a select query.
If I had to, I'd say keep small binaries in the database, and large binaries outside.
Надеюсь не нужно напоминать про размеры видеофайлов на ютюбе?
Здравствуйте, _d_m_, Вы писали:
C>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.
H>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
___>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?
Я рад за большинство СУБД, и про многофайловые базы мне рассказывать не нужно. К чему эта лирика?
___>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?
Выделенное говорит о том, что СУБД уже имеют транзакционность, а при работе с ФС ее придется прикручивать руками (не нужно мне рассказывать, что NTFS уже поддерживает транзакции). А в Firebird таки нет журнала транзакий, потому как он версионник.
C>Нет, хранение бинарной информации больших объемов в БД совершенно неприемлимо. Мы говорим о терабайтах информации. Информации, которую не возможно практически кешировать (точнее возможно, но в ограниченном объеме). Нагрузка на базу будет колоссальной и совершенно неприемлимой.
Ну ты бы ссылочки почитал для начала, прежде чем постить — там речь о терабайтах.
Оттуда:
>>Подумай над возможностью хранить сами документы на файловой системе (FTP/HTTP/.. сервере), а в базе только ссылки на них.
M>Имею глубокое убеждение, что блобам вобще не место в БД.
опана а пацаны в майкрофте об этом не знали и сделали самую большую базу изображений в мире — террасервер.
C>>Нет, хранение бинарной информации больших объемов в БД совершенно неприемлимо. Мы говорим о терабайтах информации. Информации, которую не возможно практически кешировать (точнее возможно, но в ограниченном объеме). Нагрузка на базу будет колоссальной и совершенно неприемлимой.
___> ___>Ну ты бы ссылочки почитал для начала, прежде чем постить — там речь о терабайтах.
Я почитал. Не нашел ничего, что противоречило бы утверждению о том, что большие объемы бинарной информации хранить в БД крайне неэффективно.
___>Оттуда: ___>
>>>Подумай над возможностью хранить сами документы на файловой системе (FTP/HTTP/.. сервере), а в базе только ссылки на них.
M>>Имею глубокое убеждение, что блобам вобще не место в БД.
___>опана а пацаны в майкрофте об этом не знали и сделали самую большую базу изображений в мире — террасервер.
___>По теме: ___>http://www.terraserver.com/
И где доказательства, что бинарные данные там хранятся именно в файле(ах) БД?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, _d_m_, Вы писали:
C>>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.
H>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
___>>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?
___>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?
C>По той ссылке, кстати, написано то, о чем я говорю:
C>
C>1. First of all consider the cost of serializing the document/image into the blob.
C>2. Second think about timeouts and broken streams when retreiving larger datas that aren't quite one shot.
C>3. Third, your larger files will go from d/b to web server as 4 kb chunks and each chunk will require handshaking — too much overhead — you decide.
C>4. Fourth, What really guarantees that you will never run across an image > 50KB or document > 1 MB
C>5. Fifth, Sql server is gonna break the image/document up so it fits inside it's small small pages, and obviously it'll have to peice it together in a select query.
C>If I had to, I'd say keep small binaries in the database, and large binaries outside.
Это где ваще? Немогу найти.
C>Надеюсь не нужно напоминать про размеры видеофайлов на ютюбе?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, _d_m_, Вы писали:
C>>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.
H>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
___>>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?
H>Я рад за большинство СУБД, и про многофайловые базы мне рассказывать не нужно. К чему эта лирика?
А я не знаю зачем ты приплел сюда вообще FB и показал, что есть в ней косяк, но сказал это так как-будто это достоинство.
___>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?
H>Выделенное говорит о том, что СУБД уже имеют транзакционность, а при работе с ФС ее придется прикручивать руками (не нужно мне рассказывать, что NTFS уже поддерживает транзакции).
Доступ к транзакционной файловой системе
Новая встроенная функция, GET_FILESTREAM_TRANSACTION_CONTEXT(), возвращает лексему, представляющую актуальную транзакцию, с которой связан сеанс. Эта транзакция должна быть запущена, не прервана и не зафиксирована. Получение лексемы позволяет приложению связать потоковые операции файловой системы FILESTREAM с запущенной транзакцией. Эта функция возвращает значение NULL в случае отсутствия явно запущенной транзакции.
Прежде чем транзакция будет зафиксирована или прервана, все дескрипторы файлов должны быть закрыты. Если дескриптор остается открытым за пределами области действия транзакции, дополнительные операции чтения, применяемые к этому дескриптору, завершатся ошибкой; дополнительные операции записи, применяемые к этому дескриптору, будут выполнены успешно, но фактические данные не будут записаны на диск. Аналогичным образом, если работа базы данных или экземпляра компонента Database Engine завершается, все открытые дескрипторы становятся недопустимыми.
H>А в Firebird таки нет журнала транзакий, потому как он версионник.
Здравствуйте, _d_m_, Вы писали:
H>>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
___>>>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?
H>>Я рад за большинство СУБД, и про многофайловые базы мне рассказывать не нужно. К чему эта лирика?
___>А я не знаю зачем ты приплел сюда вообще FB и показал, что есть в ней косяк, но сказал это так как-будто это достоинство.
FB в качестве примера, как там и написано . А какой косяк, позволь осведомиться? Ты походу вообще не понял, что "отдельно от табличных данных" не означает в отдельных файлах
___>>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?
H>>Выделенное говорит о том, что СУБД уже имеют транзакционность, а при работе с ФС ее придется прикручивать руками (не нужно мне рассказывать, что NTFS уже поддерживает транзакции).
___>Тыдыщь! http://msdn.microsoft.com/ru-ru/library/bb933993.aspx
[skiped]
Я смотрю ты вообще мои слова не понимаешь... Я написал, что не нужно мне рассказывать о NTFS, которая уже поддерживает транзакции. Ключевое слово выделил.
H>>А в Firebird таки нет журнала транзакий, потому как он версионник.
___>А что и в оракле тоже нет журнала транзакций?
хз. Я с Ораклом не работал, но версионникам журнал транзакций не нужен бай дизайн.
Здравствуйте, criosray, Вы писали:
___>> ___>>Ну ты бы ссылочки почитал для начала, прежде чем постить — там речь о терабайтах. C>Я почитал. Не нашел ничего, что противоречило бы утверждению о том, что большие объемы бинарной информации хранить в БД крайне неэффективно.
Б-г-г
Там нет и подверждения того:
что большие объемы бинарной информации хранить в БД крайне неэффективно.
___>>По теме: ___>>http://www.terraserver.com/ C>И где доказательства, что бинарные данные там хранятся именно в файле(ах) БД?
The Imagery table in the logical Imagery database partition contains the majority of data stored within TerraServer-USA. The Imagery table contains the "blob" field where the imagery data is stored.
Здравствуйте, _d_m_, Вы писали:
___>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.
Один простой вопрос: Раздавать ты это как будешь?
Если раздавать из файловой системы то ядро ОС может отправлять все прямо в сеть.
Из какой базы данных можно ядром ОС отправлять данные прямо в сеть?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hattab, Вы писали:
H>>>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
H>FB в качестве примера, как там и написано . А какой косяк, позволь осведомиться? Ты походу вообще не понял, что "отдельно от табличных данных" не означает в отдельных файлах
Косяк выделен жирным выше.
___>>>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?
Я стороник хранения в блобах! О чем и тут и распинаюсь. В ФС хранить — зло.
H>>>Выделенное говорит о том, что СУБД уже имеют транзакционность, а при работе с ФС ее придется прикручивать руками (не нужно мне рассказывать, что NTFS уже поддерживает транзакции).
___>>Тыдыщь! http://msdn.microsoft.com/ru-ru/library/bb933993.aspx H>[skiped]
H>Я смотрю ты вообще мои слова не понимаешь... Я написал, что не нужно мне рассказывать о NTFS, которая уже поддерживает транзакции. Ключевое слово выделил.
А я тебе показал, что есть способ использующий достоинства обоих подходов — так сказать и на ель залезть, и жопу не поцарапать:
— целостность данных;
— в рамках транзакций;
— быстрота работы с ФС напрямую;
...
H>>>А в Firebird таки нет журнала транзакий, потому как он версионник.
___>>А что и в оракле тоже нет журнала транзакций?
H>хз. Я с Ораклом не работал, но версионникам журнал транзакций не нужен бай дизайн.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, _d_m_, Вы писали:
___>>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL. WH>Один простой вопрос: Раздавать ты это как будешь? WH>Если раздавать из файловой системы то ядро ОС может отправлять все прямо в сеть. WH>Из какой базы данных можно ядром ОС отправлять данные прямо в сеть?
В большинстве случаев данные, создаваемые ежедневно, являются неструктурированными, такими как текстовые документы, изображения и видео-данные. Такие неструктурированные данные часто хранятся за пределами базы данных, отдельно от структурированных данных. Подобное разделение может привести к усложнению управления данными. Либо, если данные связаны со структурированным хранилищем, могут быть ограничены возможности файловых потоков и производительность.
Хранилище FILESTREAM объединяет компонент SQL Server Database Engine с файловой системой NTFS, размещая данные больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе в виде файлов. С помощью инструкций Transact-SQL можно вставлять, обновлять, запрашивать, выполнять поиск и выполнять резервное копирование данных FILESTREAM. Интерфейсы файловой системы Win32 предоставляют потоковый доступ к этим данным.
Для кэширования данных файлов в хранилище FILESTREAM используется системный кэш NT. Это позволяет снизить возможное влияние данных FILESTREAM на производительность компонента Database Engine. Буферный пул SQL Server не используется, поэтому данная память доступна для обработки запросов.
Здравствуйте, _d_m_, Вы писали:
H>>>>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
H>>FB в качестве примера, как там и написано . А какой косяк, позволь осведомиться? Ты походу вообще не понял, что "отдельно от табличных данных" не означает в отдельных файлах
___>Косяк выделен жирным выше.
Мда... Расшифровываю для непонятливых: при хранении бинарников в БД мы получаем профит от того, что нам не нужно париться относительно транзакционности и обеспечения целостности. Так понятнее, или все еще считаешь, что я говорю о каком-то косяке FB?
___>>>>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?
___>Я стороник хранения в блобах! О чем и тут и распинаюсь. В ФС хранить — зло.
Я тоже сторонник, об этом и написал...
H>>Я смотрю ты вообще мои слова не понимаешь... Я написал, что не нужно мне рассказывать о NTFS, которая уже поддерживает транзакции. Ключевое слово выделил.
___>А я тебе показал, что есть способ использующий достоинства обоих подходов — так сказать и на ель залезть, и жопу не поцарапать: ___>- целостность данных; ___>- в рамках транзакций; ___>- быстрота работы с ФС напрямую; ___>...
И нах ты мне это сказал? Я предупредил, что о транзакциях в NTFS мне рассказывать не нужно
Здравствуйте, _d_m_, Вы писали:
___>Хранилище FILESTREAM объединяет компонент SQL Server Database Engine с файловой системой NTFS, размещая данные больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе в виде файлов.
Удачи.
. А какой косяк, позволь осведомиться? Ты походу вообще не понял, что "отдельно от табличных данных" не означает в отдельных файлах 
