Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Oleg Krivopusk Member Откуда: Хабаровск Сообщений: 50 |
Здравствуйте. В текущей БД имеется несколько таблиц с полем Image (сканы документов) и из-за этого сильно раздут бэкап (полный), что не очень удобно для оперативного восстановления. Возникла мысль создать одну отдельную табличку для хранения "тяжелой" информации. Причем в отдельной БД. В голову пришло два варианта по поводу связки с другими таблицами: 1) Create Table img.MyImageTable( Id int identity(1,1) primary KEY, ObjectId int, -- "номер" таблицы Object_Id(Table) /проблемы при пересоздании.../ IdTable int, -- значение ключевого поля прилинокванной таблицы Img Image ) + Легко отслеживать что и откуда - Object_Id сильно привязывает.. Можно имя хранить конечно... 2) Create Table img.MyImageTable( Id uniqueidentifier primary KEY, Img Image ) + Тут просто поля связанные сделать uniqueidentifier и не заботится ни о чем - Найти откуда и чья "картинка" проблемно Что посоветуете. Или может вся затея не имеет смысла ? P.S. Просьба не отсылать в тему разностного бэкапа. |
24 июн 14, 02:54 [16209609] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
В 1м случае ссылки в обе стороны? А во 2м только в одну? Просто основные таблы должны ссылаться на эту, это же основная операция. Зачем UniqueIdentifier? Почему вы думаете что искать будет сложнее? А если индексы есть? Или не хотите зря место занимать? Отделять блобы это правильно. Но отделять в отдельную базу не обязательно. Можно в отдельную файловую группу. А оперативно восстанавливать только нужную группу, частичное восстановление. Если вам конечно только рядом поднять надо быстро. Бэкапить тоже надо соответственно. У вас 2000. Иначе использование Image ничем не объяснить. А вообще, документы можно и отдельно держать, прямо в файлах. Всё равно (из постановки вопроса) вам не нужна целостность связки данных. Папку определите, и там файлы все в куче, называть можно как GUID. По аналогии с FileStream как у 2005 SQL и выше. И работать будет лучше и удобнее. |
24 июн 14, 04:20 [16209663] Ответить | Цитировать Сообщить модератору |
Oleg Krivopusk Member Откуда: Хабаровск Сообщений: 50 |
Во 2-м случае основные таблицы и будут ссылаться на MyImageTable (имея поле IdImage ), а вот таблица MyImageTable не будет знать о том, с какой таблицы эта запись. И в принципе, надо ли это? Хотя можно запросом найти все таблицы имеющие ссылку на это поле и там искать - если уж так приспичит.
Ну 1 поле заменяет 3 по сравнению с 1-м случаем
Именно для этого. Бывает иногда нужно найти "как было" (отдельная тема :))
В данный момент тип Image - я поищу информацию о том, что лучше использовать - как то не задумывался :( |
||||||||
24 июн 14, 05:04 [16209668] Ответить | Цитировать Сообщить модератору |
aleks2
Guest |
Т.е. при восстановлении вам "Image (сканы документов)" ваще никуда не вперлись? Дык похерьте их совсем. |
||
24 июн 14, 07:23 [16209740] Ответить | Цитировать Сообщить модератору |
hider Member Откуда: Сообщений: 23 |
Oleg Krivopusk, Если Вам необходимо строить какие либо отчеты с пониманием где что лежит, то я бы использовал первую модель. А вообще если у вас SQL 2008 и более поздняя, может задуматься про FileStream? При этом администрирование базы будет проще в разы + база будет меньше весить. |
24 июн 14, 08:59 [16209907] Ответить | Цитировать Сообщить модератору |
Oleg Krivopusk Member Откуда: Хабаровск Сообщений: 50 |
В 99% случаев нужны не сканы, а например, какой текст хранимки был, какое значение поля и тп И вот чтобы узнать какое значение поля в некой таблице было вчера восстанавливать 300 Гб БД не очень интересно. P.S. Понятно, что нужна журнализация, но поддержка идет того, что досталось - помаленьку решается и этот вопрос. Не все сразу. |
||||
24 июн 14, 09:05 [16209919] Ответить | Цитировать Сообщить модератору |
Oleg Krivopusk Member Откуда: Хабаровск Сообщений: 50 |
hider, Спасибо, по-изучаю эту тему. :) |
24 июн 14, 09:06 [16209921] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Оу, у вас не 2000й. Image это старый тип. Его в новых версиях использовать не надо. Вместо него только VarBinary(max). Тут выбора нет, всё тупо и однозначно. Ещё вариант, не разделять BLOB поля (Image, VarBinanary(max) ...) от самих таблиц, т.е. можно хранить в другой файловой группе без разделения в отдельную таблу, нужно лишь указать при создании таблицы TEXTIMAGE_ON в нужной файловой группе. И никаких связок делать не надо. Такой способ неудобен лишь тем, что указывается только при создании таблицы, и если что надо перезаливать.
![]() Вы сами поняли что сказали? Или вы хотите кодировать в GUID источник данных? Тогда вы тот ещё извращенец. |
||||
24 июн 14, 11:49 [16210843] Ответить | Цитировать Сообщить модератору |
Oleg Krivopusk Member Откуда: Хабаровск Сообщений: 50 |
Mnior,
Таблицы Table1..N имеют поля IdImage (uniqueidentifier) которые ссылаются на поле Id (uniqueidentifier) таблицы MyImageTable. Тип полей uniqueidentifier только потому, что в отличии от INT (identity) не нужно "узнавать" новое значение поля ID (в MyImageTable) Можно конечно и INT - это не принципиально. |
||
25 июн 14, 01:53 [16214571] Ответить | Цитировать Сообщить модератору |
dvim Member Откуда: Санкт Петербург Сообщений: 684 |
Oleg Krivopusk,
Не у вас одного такая мысль возникла - у нас уже 2 год работает такое. В принципе - работает ....
У нас все еще осложнено репликой, а для такой таблицы можно использовать нестандартную реплику, чтобы в случае переинициализации не прокачивать все данные. Плюс UniqueIdentifier во многих вещах для такой задачи удобнее. Формируем его на клиенте и ... пишем |
||||
25 июн 14, 10:26 [16215334] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
2. Иначе ничем не отличается от IDENTITY, получается также через OUTPUT 3. GUID (кроме DEFAULT NewSequentiolID()) будет сильно деградировать индекс, ибо вставка будет в произвольное его место, в отличие от IDENTITY. Может быть для некоторых случаев очень существенным "против". Можно конечно как альтернативный ключ заводить (и даже не ключ, а поле), тогда да, согласен. И есть ещё SEQUENCE (c 2012) вместо IDENTITY и GUID, как альтернатива вашему подходу без таких неприятных побочных эффектах. А с репликой да, GUID уже вынуженно есть. |
||
26 июн 14, 13:48 [16223077] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |