Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Количество записей в таблице
|
|||
|---|---|---|---|
|
#18+
Какая СУБД без проблем может выдержать хранение и манипуляцию таблицей количество записей в которой будет не меньше 100 миллионов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2002, 20:34 |
|
||
|
Количество записей в таблице
|
|||
|---|---|---|---|
|
#18+
все зависит от того какие данные будут хранится в этих таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2002, 16:44 |
|
||
|
Количество записей в таблице
|
|||
|---|---|---|---|
|
#18+
Ну и соответственно сколько пользователей будет у базы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2002, 10:00 |
|
||
|
Количество записей в таблице
|
|||
|---|---|---|---|
|
#18+
Основным фактором является даже не кол-во таблиц, а кол-во связей и тип связей между таблицами в одном запросе. Естественно кол-во таблиц и кол-во одновременных коннектов тоже имеет значение. Кроме того таблицу в 100000000 записей, при проектировании базы всегда можно разделить на несколько (по тем или иным критериям), кстати такое деление является одним из стандартных приемов. Я бы рекомендовал под Windows использовать MS SQL 2000, под UNIX - Oracle 9i. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2002, 12:51 |
|
||
|
Количество записей в таблице
|
|||
|---|---|---|---|
|
#18+
Если возможно деление таблицы "по строкам" -- то как бы и не о чем говорить, просто нет такой большой таблицы и все ок! А вот если за подобное разделение будем платить в работе, тогда пожалуй Oracle 9i даст больше преимуществ по физическому разделению Вашей таблицы, при сохранении ее логической целостности. На вскидку не помню подобную возможность за MS SQL. Более точную консультацию наверняка можно получить у Деда Маздая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2002, 04:10 |
|
||
|
Количество записей в таблице
|
|||
|---|---|---|---|
|
#18+
Silver Если можно выделить четкие критерии, чтобы разделить таблицу вертикально, то такую таблицу надо разбивать. Используя замещающие триггеры и материализованые взгляды, такие критерии можно ввести искуственно, в любом случае на обновлении таблицы будет достигаться достаточно большой выигрыш. Проектировании базы - это комплекс проблем и их надо рассматривать в совокупности, а не выдергивать одну проблему и на ее основе выбирать сервер базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2002, 14:37 |
|
||
|
Количество записей в таблице
|
|||
|---|---|---|---|
|
#18+
2Silver В MS SQL так-же есть возможность по физическому разделению таблицы и её индексов на разные носители. Это без использования таких более сложных вещей, как замещающие триггеры, материализованые представления и разделение таблицы на разные серверы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2002, 16:10 |
|
||
|
Количество записей в таблице
|
|||
|---|---|---|---|
|
#18+
2 AISOFT: Вопрос был задан по одной проблеме? Не так ли г-н Andre? Собственно имеем право предположить что сие есть последний критерий оценки. По-моему разговор о проектировании БД в данной ситуации несколько затрагивает автора топика, посему .... Да, предложенное Вами -- реальный вариант, но вот сложность реализации -- на порядок выше чем хотелось бы. Кроме того -- если все это касается "вертикального" деления все как бы нормально, но вот если "горизонтального" .... А написание запросов, ХП и т.д.? А планы их исполнения? А не дай бог речь пойдет о перекофигурировании системы? 2 alexeyvg: a) см. вопрос б) назови промышленную СУБД которая НЕ позволяет разнести таблицы от индексов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2002, 14:29 |
|
||
|
Количество записей в таблице
|
|||
|---|---|---|---|
|
#18+
Сей вопрос меня тоже несколько волнует. Потому хочу спросить общественность по тому же поводу, но с некоторыми уточнениями. Имеется две таблицы. В одной ~ 100 млн. записей, во второй ~ 50 млн. записей. Каждый день добавляется по 100-200 тыс. записей. Таблицы связаны по двум полям. Размер записи ~ 100 байт. Интересует следующее: 1. Скорость добавления записей. (на сколько будет тормозить проверка на ограничении целостности) 2. Периодически надо обновлять данные в таблице 1 по связи из таблицы 2. П.с. О разделении пока речи не идет. Из-за спецификации бизнес-процесса делить можно помесячно (и скорее всего будет так делаться), но надо расчитывать на то, что кол-во ежедневно добавляемых данных растет с каждым днем) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 10:28 |
|
||
|
|
start [/forum/topic.php?fid=35&msg=32040487&tid=1554475]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
82ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 9ms |
| total: | 181ms |
| 0 / 0 |
