Здравствуйте, Blackmore, Вы писали:
B>Там должно быть 2 функции — SaveDocument(Stream oDoc) и GetCoument(int nDocID). База — MSSQL. Есть где-набудь такая готовая либа или открытый код?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Blackmore, Вы писали:
B>>Там должно быть 2 функции — SaveDocument(Stream oDoc) и GetCoument(int nDocID). База — MSSQL. Есть где-набудь такая готовая либа или открытый код?
A>что мешает самому это написать?
Думал просто, что уже готовое есть — бери и юзай под .NET
Здравствуйте, Blackmore, Вы писали:
B>Здравствуйте, adontz, Вы писали:
A>>Здравствуйте, Blackmore, Вы писали:
B>>>Там должно быть 2 функции — SaveDocument(Stream oDoc) и GetCoument(int nDocID). База — MSSQL. Есть где-набудь такая готовая либа или открытый код?
A>>что мешает самому это написать?
B>Думал просто, что уже готовое есть — бери и юзай под .NET
Эх как ты разогнался.
Рядом со стримом тебе понадобится как минимум имя файла и content-type, а также last-modified и etag во многих сценариях. А потом внезапно окажется что хранить кучу блобов в MS SQL неэффективно и ты будешь спрашивать как их хранить вне MS SQL.
Здравствуйте, gandjustas, Вы писали:
G>Рядом со стримом тебе понадобится как минимум имя файла и content-type, а также last-modified и etag во многих сценариях. А потом внезапно окажется что хранить кучу блобов в MS SQL неэффективно и ты будешь спрашивать как их хранить вне MS SQL.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, gandjustas, Вы писали:
G>>Рядом со стримом тебе понадобится как минимум имя файла и content-type, а также last-modified и etag во многих сценариях. А потом внезапно окажется что хранить кучу блобов в MS SQL неэффективно и ты будешь спрашивать как их хранить вне MS SQL.
___>А чего бы это вдруг неэффективно хранить блобы?
1)Значительное увеличение размера базы, что сказывается на времени бекапа-рестора
2)Блоб из СУБД стримается в режиме forward-only считывания, для random read-write приходится извращаться.
3)Доставание блобов из таблиц создает дополнительную, но абсолютно ненужную нагрузку на SQL Server
Для блобов в 4k-64k на запись это малозаметный эффект дает. Для более крупных файлов уже начинается геморрой.
Здравствуйте, gandjustas, Вы писали:
G>1)Значительное увеличение размера базы, что сказывается на времени бекапа-рестора
partial backups. Полный бэкап придётся делать всё равно.
G>2)Блоб из СУБД стримается в режиме forward-only считывания, для random read-write приходится извращаться.
Если вы запихиваете в blob неатомарные данные — это самая меньшая из ваших проблем
Тем не менее — http://msdn.microsoft.com/en-us/library/bb399384.aspx
G>3)Доставание блобов из таблиц создает дополнительную, но абсолютно ненужную нагрузку на SQL Server G>Для блобов в 4k-64k на запись это малозаметный эффект дает. Для более крупных файлов уже начинается геморрой.
Для более крупных есть FILESTREAM, Он умеет отдавать поток напрямую с ФС.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>1)Значительное увеличение размера базы, что сказывается на времени бекапа-рестора S>partial backups. Полный бэкап придётся делать всё равно.
Это не решение. В любом случае база будет пухнуть без толку.
G>>3)Доставание блобов из таблиц создает дополнительную, но абсолютно ненужную нагрузку на SQL Server G>>Для блобов в 4k-64k на запись это малозаметный эффект дает. Для более крупных файлов уже начинается геморрой. S>Для более крупных есть FILESTREAM, Он умеет отдавать поток напрямую с ФС.
А толку? все равно этот поток будет прокачиваться через SQL Server. Надо получать имя файла и открывать его для чтения напрямую. Тогда все будет ОК.
Еще раз: хранить большие блобы в базе — плохо. Их надо хранить вне и обращаться к ним вне базы. FileStream как раз для этого и был создан.
Здравствуйте, gandjustas, Вы писали:
G>>>1)Значительное увеличение размера базы, что сказывается на времени бекапа-рестора S>>partial backups. Полный бэкап придётся делать всё равно. G>Это не решение. В любом случае база будет пухнуть без толку.
Будет пухнуть не база, а папка в которой хранятся данные FILESTREAM.
S>>Для более крупных есть FILESTREAM, Он умеет отдавать поток напрямую с ФС. G>А толку? все равно этот поток будет прокачиваться через SQL Server. Надо получать имя файла и открывать его для чтения напрямую. Тогда все будет ОК. OpenSqlFilestream API именно это и делает.
А на практике достаточно даже dataReader.GetSqlBinary(), или такого кода:
private static void WriteToStream(IDataReader reader, int binaryDataOrdinal, Stream stream, int bufferSize)
{
byte[] buffer = new byte[bufferSize];
long position = 0;
long bytesReaded;
do
{
bytesReaded = reader.GetBytes(binaryDataOrdinal, position, buffer, 0, bufferSize);
stream.Write(buffer, 0, (int)bytesReaded);
position += bytesReaded;
}
while (bytesReaded == bufferSize);
}
G>Еще раз: хранить большие блобы в базе — плохо. Их надо хранить вне и обращаться к ним вне базы. FILESTREAM как раз для этого и был создан. Сэкономив на копейках, придётся переизобретать транзакции, полнотекстовый поиск, бэкап, контроль доступа и репликацию. Оно вам надо?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>Я не сразу заметил, что вы явно разделяете FILESTREAM и MS SQL, и файлстрим, по-вашему — это не способ хранить блобы в базе. S>
S>хранить кучу блобов в MS SQL неэффективно
S>...
S>Их надо хранить вне и обращаться к ним вне базы. FileStream как раз для этого и был создан.
S>
S>От умеете же запутать самый простой вопрос
Ну начнем с того что топикстартер хотел готовую либу. Я начал объяснять что готовой либы с таким интерфейсом не будет, по вполне определенным причинам, в том числе связанным с неэффективность хранения блобов в БД.
Здравствуйте, gandjustas, Вы писали:
G>Ну начнем с того что топикстартер хотел готовую либу. Я начал объяснять что готовой либы с таким интерфейсом не будет, по вполне определенным причинам, в том числе связанным с неэффективность хранения блобов в БД.
Sharepoint же как-то справляется с "неэффективностью хранения", почему сторонняя библиотека не может использовать FILESTREAM?
Но готового ничего не будет — слишком много различных юз-кейзов, чтобы написать что-то универсальное.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Ну начнем с того что топикстартер хотел готовую либу. Я начал объяснять что готовой либы с таким интерфейсом не будет, по вполне определенным причинам, в том числе связанным с неэффективность хранения блобов в БД.
S>Sharepoint же как-то справляется с "неэффективностью хранения"
Никак он не справляется. Несколько тысяч файлов уже "много", сотня тысяч уже "слишком много".
S>почему сторонняя библиотека не может использовать FILESTREAM? S>Но готового ничего не будет — слишком много различных юз-кейзов, чтобы написать что-то универсальное.
Во-во
Здравствуйте, Sinix, Вы писали:
S>>>Для более крупных есть FILESTREAM, Он умеет отдавать поток напрямую с ФС. G>>А толку? все равно этот поток будет прокачиваться через SQL Server. Надо получать имя файла и открывать его для чтения напрямую. Тогда все будет ОК. S>OpenSqlFilestream API именно это и делает.
Этот API по сравнению с обычным Transact-SQL не транзакционный, потому, к примеру, удалить или переименовать файл не получится. Автору темы как будто от библиотеки не нужен метод удаления файла, но чую, это он просто не подумал.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Sinix, Вы писали:
S>>>>Для более крупных есть FILESTREAM, Он умеет отдавать поток напрямую с ФС. G>>>А толку? все равно этот поток будет прокачиваться через SQL Server. Надо получать имя файла и открывать его для чтения напрямую. Тогда все будет ОК. S>>OpenSqlFilestream API именно это и делает. R>Этот API по сравнению с обычным Transact-SQL не транзакционный, потому, к примеру, удалить или переименовать файл не получится.
Не совсем так: http://msdn.microsoft.com/en-us/library/bb933972.aspx
...
When the file is opened for write access, the transaction is owned by the FILESTREAM agent. Only Win32 file I/O is allowed until the transaction is released. To release the transaction, the write handle must be closed.
Файлы FILESTREAM используют служебные имена, метаданные реальных файлов надо хранить самостоятельно, как привило — в той же таблице, что и сам blob.
R>Автору темы как будто от библиотеки не нужен метод удаления файла, но чую, это он просто не подумал.
Удаляется простым удалением записи из таблицы.
Здравствуйте, Sinix, Вы писали:
S>>>>>Для более крупных есть FILESTREAM, Он умеет отдавать поток напрямую с ФС. G>>>>А толку? все равно этот поток будет прокачиваться через SQL Server. Надо получать имя файла и открывать его для чтения напрямую. Тогда все будет ОК. S>>>OpenSqlFilestream API именно это и делает. R>>Этот API по сравнению с обычным Transact-SQL не транзакционный, потому, к примеру, удалить или переименовать файл не получится. S>Не совсем так: http://msdn.microsoft.com/en-us/library/bb933972.aspx
Ага, я к тому, что для всех сценариев CRUID все равно так или иначе придется задействовать Database Engine.
R>>Автору темы как будто от библиотеки не нужен метод удаления файла, но чую, это он просто не подумал. S>Удаляется простым удалением записи из таблицы.
Я и говорил, что стандартным Transact-SQL можно, что через Win32 API нельзя.
Здравствуйте, rsn81, Вы писали:
R>Ага, я к тому, что для всех сценариев CRUID все равно так или иначе придется задействовать Database Engine.
Там по-любому напрямую не выйдет — потребуется PathName(), при обращении буде использоваться filter driver. А какая разница?
R>Я и говорил, что стандартным Transact-SQL можно, что через Win32 API нельзя.
А чем так принципиально наличие winapi?
Здравствуйте, Sinix, Вы писали:
R>>Я и говорил, что стандартным Transact-SQL можно, что через Win32 API нельзя. S>А чем так принципиально наличие winapi?
Ну это как раз не ко мне вопрос. Выше вы с gandjustas дошли до того, как работать с файлами в SQL Server, не задействуя Database Engine. Я только встрял, что в таком варианте не все сценарии работы будут покрыты.
Здравствуйте, rsn81, Вы писали:
R>Ну это как раз не ко мне вопрос. Выше вы с gandjustas дошли до того, как работать с файлами в SQL Server, не задействуя Database Engine. Я только встрял, что в таком варианте не все сценарии работы будут покрыты.
Я ещё раз повторю: на самом деле db engine всегда задействуется, только очень тонкой прослойкой. А все разборки от того, что gandjustas начал с
хранить кучу блобов в MS SQL неэффективно
а закончил
Их надо хранить вне и обращаться к ним вне базы. FileStream как раз для этого и был создан.
Для меня это оччень походит на высказывание "Работа с unmanaged в дотнете очень неэффективна ...(перерыв на пару постов с ответами про интероп)... надо использовать нативные библиотеки и интероп, он как раз для этого и был создан".
Здравствуйте, Sinix, Вы писали:
S>Для меня это оччень походит на высказывание "Работа с unmanaged в дотнете очень неэффективна ...(перерыв на пару постов с ответами про интероп)... надо использовать нативные библиотеки и интероп, он как раз для этого и был создан". S>Диверсант, как есть диверсант
Ага, учитывая, что сам .NET внутри себя интеропиться не стесняясь.
