Лучше иметь логическое значение (важный флаг) как атрибут или в отдельной таблице?

Question

У меня есть три случая, и я не знаю, какое решение лучше для каждого из них, но все они относятся к логическим атрибутам

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

• Те же ссылки, что и выше, имеют атрибут посещенияэто постоянно обновляется, но в таблице с более чем 1 миллионом строк максимум будет 10 000 или 20 000.

• У меня есть таблица со страницами и один атрибут дляукажите, был ли каждый обработан или нет.В конце (после обработки) все строки должны быть истинными.

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

Я думаю,то есть: атрибут в первом случае, таблица во втором, и я не знаю для третьего.

Приветствуются другие решения (например, индекс, возможно).

ВАЖНО: обатаблицы (страницы и ссылки) могут содержать более миллиона строк.

Answer 1

Я бы сказал, столбцы для первого случая, таблицы для второго и столбцы для третьего.

Ваша главная задача, в зависимости от масштаба вашей базы данных, может состоять в том, чтобы отделить часто обновляемые данныеиз основной массы остальных.Вот почему я бы предложил стол для второго случая.Однако вы можете разумно использовать функцию «HOT» в PostgreSQL, что означает, что обновления не приводят к раздутию таблицы, если обновляемые столбцы не проиндексированы , а не .Но, вероятно, все еще хорошей идеей будет держать трафик подальше от больших таблиц из-за потенциально большого времени поиска, поддержания автовакуума в норме и т. Д. Если вы обеспокоены, я бы проверил это.

Answer 2

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

Я бы посоветовал просто положить все на стол, если только у вас нет причин не делать этого, и сделать это.

Но самое главное: какая СУБД ?