Удаление всех ФК из моих таблиц записи

0

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

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

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

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

  • 0
    Вы можете попробовать добавить foreign_key_checks = 0 в my.cnf и перезапустить. Это пропустит шаг проверки ограничения для таблиц. Если вы хотите, вы также можете установить его для каждой сессии.
Теги:
database
database-design

1 ответ

0
Лучший ответ
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 в базе данных, потому что в противном случае у вас есть все эти плохие данные.

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

Если ответы "100% уверены", то второй вопрос не имеет значения. Отбросьте fk и вставьте данные со скоростью и уверенностью.

Поделиться
  • 0
    Уверенный -> Ну, я не думаю, что кто-то может быть уверен на 100%. Несоответствия данных всегда происходят. Размер поисков -> Большинство маленькие, несколько тысяч строк. Некоторые из них огромны, как мировой почтовый поиск, который превратится в миллион, когда он будет полностью заселен. Я гоняюсь за производительностью, поэтому все, что дает мне лучшую производительность, чтобы я мог отображать данные в реальном времени для своих пользователей, - это то, что я хотел бы.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню