Доброго дня.
Проектируется классический клиент-сервер: FB 2.0 на Win; ADO.Net provider.
Интересуют 2 вопросы (поиски по инету + ibase.ru ничего вразумительного не дал, хотя может не там искал):
1) предполагается разделение данных на оперативные(текущие,необходимые) и архивных(учтенных,необходимых только по запросу). Так вот, где хранить архивных данные, учитывая необходимость не дать влиять чтение архивных данных на скорость работы с оперативными.
Мои варианты:
1) все в одной таблице - не есть гуд для оперативных данных. отпадает.
2) архивных в отдельной таблице, НО в одной БД
3) архивных в отдельной ВНЕШНЕЙ таблице, на разных винтах
4) архивные в отдельной БД - гемор при необходимости выборки и из опер. и из арх. данных
ВОПРОС: что посоветуете и кто, что использует ?
2) аналогичный вопрос про хранение БЛОБОВ (binary и text). Как известно, изменение блоба порождает его копию в БД (версию), соотв. размер БД может разростаться не кисло, соотв. (хотя могу ошибаться) скорость работы сервера с БД падает. Итак, где же хранить блобы, привязанные логически в записи (например товар и его фото): 1) в одной таблице - как повлияет на скорость выборки; 2) в отдельной табл.; 3) в отд. внешней табл. на другом физ. винте 4) в отдельной БД.
Сразу скажу, что до своих тестов таких ньюансов еще не дошел, если кому-то не трудно поделится опытом, буду благодарен.
Вопрос о архивных данных и блобах
Re: Вопрос о архивных данных и блобах
Вот тебе ещё вариант. Может, не самый удачный, у меня пока так сделано. Две отдельные базы, одна оперативная, другая архивная. Архивная включает в себя данные оперативной (репликация). Оперативная - для работы и оперативных отчётов (без копания далеко вглубь), архивная - для полных и глубоких отчётов.ARM писал(а):где хранить архивных данные, учитывая необходимость не дать влиять чтение архивных данных на скорость работы с оперативными.
В дальнейшем по мере роста архивную можно перевести на другую платформу (или оставить, если в FB OLAP будет).
Зависит от того, как именно ты работаешь с блобами.ARM писал(а):Итак, где же хранить блобы, привязанные логически в записи (например товар и его фото): 1) в одной таблице - как повлияет на скорость выборки; 2) в отдельной табл.; 3) в отд. внешней табл. на другом физ. винте 4) в отдельной БД.
Хранение в той же таблице в перемешку с данными рекомендуемо только в одном случае - когда при листании грида с записями картинки у тебя выводятся сразу, либо отображаются прямо в гриде.
В любом другом случае - отдельное хранение, получение по дополнительному запросу.
Хранение блобов в той же таблице, если блоб влазит на одну страницу с данными, неоправдано - данные будут разрежены, чтение запросами таких данных замедлится, дисковая активность возрастёт.
Если блоб у тебя заведомо не влазит на страницу с данными, он хранится на отдельных страницах и на скорость выборок не влияет. Кроме того, понятно, что хранение в той же таблице упростит логику базы.
Потому одним из факторов является размер хранимых картинок.
причем это самый поганый по трафику и ресурсам вариант.когда при листании грида с записями картинки у тебя выводятся сразу, либо отображаются прямо в гриде.
и это можно увидеть в IBAnalyst.хранение блобов в той же таблице, если блоб влазит на одну страницу с данными, неоправдано - данные будут разрежены, чтение запросами таких данных замедлится, дисковая активность возрастёт.
Поддерживаю мнение Мерлина. Первостепенно для меня скорость работы/рестора оперативных данных/БД, поэтому сделаю разделение данных по разным БД.Merlin писал(а):Насчёт альтернативы архив в базе/отдельно. Вопрос упирается в размер базы как таковой в смысле времени рестора versus возня с герерогенными запросами, всё остальное по барабану.
Всем спасибо за комменты. Всех благ.
Re: Вопрос о архивных данных и блобах
Вот я тоже хотел поинтересоваться по поводу хранения блобов в отдельных таблицах, так как ещё до релиза FB2 кто-то упоминал что переделают в FB2 и блобы будут храниться всегда в отдельных страницах... или я что-то попутал? Или ситуация не изменилась?WildSery писал(а): Хранение в той же таблице в перемешку с данными рекомендуемо только в одном случае - когда при листании грида с записями картинки у тебя выводятся сразу, либо отображаются прямо в гриде.
В любом другом случае - отдельное хранение, получение по дополнительному запросу.
Хранение блобов в той же таблице, если блоб влазит на одну страницу с данными, неоправдано - данные будут разрежены, чтение запросами таких данных замедлится, дисковая активность возрастёт.
Если блоб у тебя заведомо не влазит на страницу с данными, он хранится на отдельных страницах и на скорость выборок не влияет. Кроме того, понятно, что хранение в той же таблице упростит логику базы.
Потому одним из факторов является размер хранимых картинок.
, жаль конечно,будем надеяться что в будущем появится