Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
5. Проблема перехода на следующий период
|
|||
|---|---|---|---|
|
#18+
Допустим, есть база, содержащая некоторые расчетные данные. Причем за один месяц в таблицах базы может накапливаться до нескольких миллионов записей. За год – соответственно до нескольких десятков миллионов. База в перспективе рассчитана на несколько десятков лет. Вопрос: Целесообразно ли с точки зрения сохранности информации и быстроты доступа к ней хранить все данные в одних и тех же таблицах или лучше разбивать данные по таблицам, отвечающим за определенный период (месяц, год)? Все ребята, с кем я советовался, отвечали, что для SQL Server объем информации в таблицах – это не проблема. Главное – правильно построенная архитектура базы. Объем данных в таблицах их баз не превышал 2 миллионов записей. С правильно построенной архитектурой базы я полностью согласен, но насчет того, что объем информации – не проблема у меня сомнения. Если кто встречался с подобной проблемой, проконсультируйте, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2003, 16:49 |
|
||
|
5. Проблема перехода на следующий период
|
|||
|---|---|---|---|
|
#18+
Если инфа используется часто - тогда конечно хранить всё вместе. А если очень редко и ли вообще не используется то можно скидывать в оддельные таблицы (архивные) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2003, 16:59 |
|
||
|
5. Проблема перехода на следующий период
|
|||
|---|---|---|---|
|
#18+
Читай про нормализацию базы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2003, 15:50 |
|
||
|
5. Проблема перехода на следующий период
|
|||
|---|---|---|---|
|
#18+
Скажем так, объемы таблиц влияют на скорость отработки запросов... кто сомневается, пусть сравнит таблицу с 10 строчками и с 10 000 000 и получет ответ. А По поводу архивирования... это тебе лучше гвоорить с заказчиками, может им данные годовой давности в таком виде не нужны и их можно вынести вообще в отдельную БД, или придумать что еще.... если необходим большой период, а табица слишком тормозная.... можно попытаться разбить на 2.... но вот только по собственному опыту могу сказать, что синхронизировать их очень неприятно.... особенно если период отчета начинается в старой таблице а заканчивается в новой.... приятного мало... такое всеж следует делать, когда другие варианты исчерпаны.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2003, 11:07 |
|
||
|
5. Проблема перехода на следующий период
|
|||
|---|---|---|---|
|
#18+
В Oracle есть так называемый partition. Вы можете разбить таблицу на части по какому-либо признаку. При этом скорость доступа значительно увеличивается. Может, есть что-то подобное у Microsoft ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2003, 11:44 |
|
||
|
|

start [/forum/topic.php?fid=16&fpage=234&tid=1348924]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
| others: | 312ms |
| total: | 438ms |

| 0 / 0 |
