Отношения БД и программные решения для обеспечения согласованности (производительности) - PullRequest
Новая
       19

Отношения БД и программные решения для обеспечения согласованности (производительности)

1 голос
/ 27 июля 2011

С моей точки зрения, база данных всегда является узким местом. Так как я могу масштабировать мощность процессора до любого необходимого значения. Ресурсы БД ограничены даже при кластеризации или репликации. Я могу ошибаться, но это мои достижения в облачном ПО.

Так что я думаю, что если отношения не будут задействованы, БД спасет ресурсы БД, не так ли?

Например, если у вас есть таблица пользователей и таблица user_friends. Внешний ключ в user_friends является первичным ключом таблицы пользователей. Так что, если у меня есть отношения типа ON DELETE в таблице пользователей -> DELETE FROM user_friends ... база данных будет в магии, чтобы сохранить постоянство и выполнить все необходимые запросы. Разве не быстрее, если мое программное обеспечение выполнит два простых запроса: УДАЛИТЬ ОТ пользователей, ГДЕ user_id ... и УДАЛИТЬ ИЗ user_friends, ГДЕ friend_id ...

Конечно, падение будет возможным несоответствием, но не уменьшает ли это нагрузку на БД?

1 Ответ

0 голосов
/ 27 июля 2011

По моему мнению, вы должны использовать независимые объекты (строки), а не отношения, поэтому вам больше не нужно использовать сложные запросы.Кроме того, вам будет намного проще кэшировать ваши запросы (как на стороне сервера, так и на стороне db).

Чтобы предотвратить несогласованность, вы должны использовать:

  • транзакций, поэтому все «связанные» объекты данных обновляются.
  • sharding, поэтому вам не нужно будет масштабировать вашу БД по вертикали.Горизонтально намного проще (в большинстве случаев).
  • репликация, поэтому, когда сервер выходит из строя, ваше приложение не становится несовместимым.

Так что, в принципе, это, вероятно, сложнеекодировать, но это даст вам лучший дБ-дизайн с невероятной производительностью и очень масштабируемым.

Кстати. если вы не захотите использовать отношения, я бырекомендую использовать no-SQL-db.Базы данных SQL довольно трудно масштабируются (по сравнению с базами данных без SQL) и вызывают значительные накладные расходы, когда вы не используете отношения (также по сравнению с базами данных без SQL).

...