Удаление всех ФК из моих таблиц записи - PullRequest
0 голосов
/ 19 января 2011

У меня есть несколько очень тяжелых таблиц с интенсивной записью (таблицы отслеживания пользователей), которые будут писать без остановки. Проблема в полностью нормализованной схеме, у меня будет 16 внешних ключей. Некоторые ключи предназначены исключительно для поиска по ссылкам, некоторые - как связывание идентификатора пользователя, идентификатора сеанса пользователя, идентификатора активности и т. Д.

С этим большим количеством FK для таблицы с интенсивной записью производительность является проблемой. (У меня есть сайт с пользовательским контентом, который нуждается в обновлениях в режиме реального времени). Поэтому я планирую отбросить все FK для этих таблиц с интенсивной записью, но перед этим я хочу узнать, как еще можно связать данные? Когда люди говорят в коде, что именно мы делаем на уровне кода, чтобы связать данные вместе, как я предполагаю в приложении, у нас не может быть отношений?

Во-вторых, если я не буду использовать FK, я предполагаю, что данные будут согласованными, пока записывается идентификатор corect? Не похоже, если идентификатор участника равен 2000, вместо этого будет написано 3000, если по какой-либо причине не используется FK?

Наконец, это не повлияет на присоединения, верно? Хотя я надеюсь избежать объединений, мне может понадобиться. Но я предполагаю, что FKs или нет, соединения все еще могут быть сделаны как есть?

1 Ответ

0 голосов
/ 19 января 2011
Secondly, if I dont use FKs I assume data will still be consistent
as long as the the corect ID is written?

Да.

Lastly, this will not effect joins right?

вправо.

When people say in the code, what exactly are we doing at the 
code level to keep data linked together

Это реальный вопрос.На самом деле, действительно реальных двух вопросов:

1) Насколько вы уверены, что все входные значения действительны и не нуждаются в проверке.

2) Насколько велики ссылки на справочные таблицы?

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

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

Для этой комбинации этокешировать таблицы в приложении непрактично, и если вы отбрасываете fks и делаете поиск из приложения, это даже медленнее, чем наличие fk в базе данных.

Если ответы «на 100% уверены», то2-й вопрос не имеет значения.Брось фк и вставь данные со скоростью и уверенностью.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...