Ситуация такая.... есть таблица X. В неё попадает много данных. Через какое-то время данные устаревают, но остаются нужны. В текущий момент необходимы записи последнего периода. Остальные - иногда, по мере необходимости и довольно редко. Таблица ДОЛЖНА висеть на энтити. Возможно в последующем времени - хибернейт или иная альтернатива.
Хочется сделать автоматическое создание новой таблицы для нового года. Но создание нового бина для этой таблицы каждый год в процессе работы системы - это изменение системой самой себя - не выход. Подумалось.... Может в EJB3.0 , хибернейте, али каком-то ином фреймворке можно подвесить ряд таблиц как одну.
Вернее устроить физическое вертикальное деление сущности.
ЗЫ: Таких таблиц много, посему надо бы общее решение... частных, проверенных - у меня валом :-/
Да и просто идеи не помешают. У меня их много, но могут быть и лучше ведь

Ты же вроде с Oracle работаешь, так почему бы вам не использовать его партишенинг?

Одно из лучших решений данной проблемы, которые выработало человечество, заключается в разделение всех данных на оперативное и архивное подмножество. Но - внимание! - это не значит, что надо тупо дублировать каждую таблицу. В общих чертах идею можно описать так.

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

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

Кроме этого, ты определяешься с перечнем функций/отчетов, которые будут использовать эти архивные данные, и в соответствии с этим разрабатываешь структуру архивных таблиц. Тут важно понимать, что это не обязательно должна быть копия оперативных таблиц. Фактически, архов - это множество неизменяемых данных только для пополнения. В силу этого многие принципы датабазного дизайна, такие как нормализация, здесь оказываются мало применимы. Приведу простой пример.

Допустим, у нас есть связь документы-юзеры. При классическом подходе мы должны иметь таблицы Документ, Юзер и из документа ссылаться на юзера по USER_ID. Но тут возникают свои нюансы. В частности, мы не можем просто так взять и удалить юзера - надо как-то решать, что делать с внешними ключами, которые на него ссылаются. Технических решений тут много, от автоматического обнуления ссылок до фиктивного удаления юзера путем изменения его статуса, но тут все во многом определяется семантикой данных. Нужен ли нам весь этот геморрой в архиве? Определенно нет. Как от него избавится? А очень просто, если вспомнить, что архив - это хранилище временных слепков состояний системы. И нет ничего страшного, если мы немного разнормализуем нашу структуру данных. Например, засунем инфу о юзере прямо в документ. Сколько именно инфы - зависит от требований. Например, для большинства видов аналитики будет достаточно ID и имя юзера. Но возможно, что понадобится что-то еще, например, должность или отделение. Ну и на здоровье, добавим еще полей.

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

Скажешь, все это слишком геморройно? А никто и не говорил, что будет легко. Во всяком случае, это намного лучше, чем каждый год заводить новую таблицу. И тем более лучше, чем хранить в одной таблице все записи от сотворения мира. Почему - могу поаргументировать. Но ты сначала скажи, что обо всем этом думаешь.

Ить, то-то и оно! Оракл сугубо для табличек и индексов :-/
В новой(кардинально другой) версии системы.
Во время девелопа - оракл, у клиента пока - оракл. Но систему могут пхнуть куда угодно помодульно, хоть на LDAP или XML файлики (некоторые модули). Вобщем планируется такой себе вездеход.
Отседа и вытекает что оракл для нас нонеча - лишь безликая СУБД. И его фишки ни при каких обстоятельствах не юзать(!). Хотя в предыдущей системе оракл гоняли в хвост и в гриву, выдоили всё что могли
А эта задумка должна пахать где угодно - оракл, сибэйс, эмэс, интербэйс, дибидва и пр...


Вкуриваю понемногу... Завтра "сапоги надену на свежую голову " - ещё подумаю. Мысль тут, несомненно, копошится и меня терзает.

На прошлой работе была такая штука: делали базу - полную копию в плане структуры таблиц. Но без единого гвозд.. тьфу! уникального индекса и форейн ключей. И периодически сливали туда всю инфу. Я ещё такой вариант обдумаю. Но там риалтаймом не особо пахло... а тут будет критична скорость...

Stampede, респект, завтра попробую выкроить время - поискать книжки умные на эту тему... надеюсь на продолжение совета после моего "вкурения"
Добавлено @ 20:51
ЗЫ, пока ещё вечер не придавил...
Возможно, записи из архива могут понадобиться в реальном времени. Не для полуношного копания админа по конкретному поводу и запросу свыше, а в любой момент времени, как "оперативные данные". Тогда их прозрачно бы подтягивать...
Если по годам делить, к примеру, то во время выборки мы точно знаем надо ли нам лезть в историю, али нет. Лан, завтра уже обмозгую

Ты конечно поищи, но от себя хочу порекомендовать одну из лучших книжек (если не самую лучшую) по датабазному дизайну, которые мне когда-либо встречались: Oracle Design: The Definitive Guide - Dave Ensor, Ian Stevenson. У меня эта книжка есть в русском переводе, бумажная. Не исключено, что где-нибудь в сети лежит и электронная версия. Очень советую поискать.

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



Тут тоже есть решения. Например, создать view, которое внутри использует объединение (union) и тем самым позволяет привести имена полей/структуру архива к эквивалентам опертивных таблиц и тем самым "упрозрачить" доступ к разнородным источникам.

Ты эта, спрашивай

Это я бы сделал... только вот трабла как раз в том, что нельзя :-/
Или свой жава-механизм(и тогда уж общий для всех нужных таблиц), или стандартный(что гораздо приемлемей для разработки и поддержки), встроенный в какой-то из фреймворков...
Вьюх не будет... Посему... как бы... надо бы тот же юнион средствами джавы..
Сейчас доделаю кой-чего - сяду думать и спрашивать.
Добавлено @ 11:03

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

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

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

Будет таблица Х, для неё будет создана таблица Хх.
В Хх будет аналогичная структура данных, без уникальных индексов, форейн и праймари ки. Плюс, добавится поле timestamp, которое будет заполняться при вставке этой хисторизированной записи.

При изменении какого-либо поля в таблице X, её текущее состояние(строки) будет перенесено в Xx, с пометкой текущей таймстэмпы. Запись в оперативной таблице будет модифицирована.


Для не столь важных таблиц, возможно реализуем сериализацию Value Object'ов в Блобы. В таблице вида(id integer, type varchar(255), VO BLOB, stamp date) будет храниться тип VO(имя класса, сериализованный обжект, дата сериализации).

То есть, для всех таблиц - хисторизация в одну, различия по type, который указывает на VO, который, в свою очередь, содержит данные конкретной записи конкретной таблицы.

Для динамических таблиц(которые меняют структуру в процессе работы системы) хисторизацию додумаем ещё... Пока только ясно, что для удалённых полей историю их ранних значений всё равно следует хранить....


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

Всем, кому есть что сказать, велкам 

Stampede,  ваш ход, гроссмейстер ;)