Новый столбец или другая таблица

Эта проблема беспокоит меня всякий раз, когда возникает необходимость добавить новое поле в таблицу. Здесь таблица содержит около 1,5 млрд записей (секционированных и разделенных таким образом, что это физически разделенные файлы). Теперь мне нужно добавить nullable поле varchar (1024), которое будет принимать некоторые строки JSON. Возможно, что в будущем длина поля должна быть увеличена для размещения более длинных строк.

Вот аргументы

  1. все существующие строки будут иметь значение null значения для этого поля. (избр. новая таблица)
  2. только 5% вновь вставленных записей будут иметь значение для этого. (избр. новая таблица)
  3. большинству текущих запросов в таблице потребуется доступ к этому полю. (избр. alter)

Я не уверен, что выделение памяти запроса играет какую-то роль в этом, основываясь на том, где я храню.

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

4 2
mysql database rdbms

4 ответа:

Ну, если ваши старые записи не должны иметь это поле varchar , вы должны поместить его в другую таблицу и при извлечении данных дать соединение с первичным ключом другого

0

Это не большое дело, вы можете просто добавить столбец в эту таблицу и для этого просто установите null для этого нового столбца.

0

Я думаю, что, независимо от 3 ситуаций, которые вы положили, вы должны Изменить существующую таблицу, а не создавать новую.

Мои рассуждения таковы:
1) ваша таблица очень большая (1,5 миллиарда строк). Если вы создадите новую таблицу, вы реплицируете PK для 1,5 миллиардов строк в новой таблице.

Это вызовет следующие проблемы:
а) потеря пространства БД.
б) трудоемкий. Заполнение новой таблицы 1,5 млрд строк и обновление их PKs-нетривиальное упражнение.
в) откат-исчерпание сегмента. Если сегменты отката имеют недостаточное пространство во время вставки новых строк, вставка завершится неудачей. Это увеличит фрагментацию БД.

С другой стороны, все эти проблемы можно избежать, изменив таблицу:
1) нет никаких потерь пространства.
2) операция не займет много времени.
3) отсутствует риск отказа сегмента отката или фрагментации БД.

Так что измени таблица.

0

Оба этих подхода имеют свои достоинства и недостатки. Я думаю, что нашел компромисс между этими двумя вариантами., который имеет преимущества обоих подходов

  • Создайте новую таблицу для хранения строки JSON. Эта таблица имеет тот же первичный ключ, что и первая таблица. Говорят, первая таблица является клиент, и вторая таблица Customer_json_attributes

  • Измените текущую таблицу (customer), чтобы добавить флаг, указывающий на наличие значения в поле JSON. скажем json_present_indicator чар (1).

  • Приложение для установки json_present_indicator= 'Y' в первой таблице, если есть значение для поля JSON во второй таблице, если не установлено значение ' N '

    • Select запросы будут иметь левое соединение, имеющее json_present_indicator = ‘Y’ в качестве условия соединения. Это будет эффективным соединением, так как запрос будет искать вторую таблицу только тогда, когда индикатор ‘Y’. Помните, что только 5% записей будут иметь значение в поле JSON
0