Как думать о реляционной базе данных в Интернете

Question

Я занимался простым веб-программированием на Python, и у меня есть общее представление о большинстве частей, связанных с созданием и обслуживанием веб-страниц. Тем не менее, я слабо разбираюсь в использовании реляционных баз данных в качестве способа хранения и извлечения данных. Я понимаю основы SQL-запросов и проектирования баз данных, но у меня возникают проблемы с пониманием того, что я должен делать, чтобы обеспечить параллельный доступ (среди прочего).

Имея это в виду, у меня есть пара довольно специфических вопросов. Однако для каждого вопроса мне лишь частично интересен ответ на сам вопрос. Меня больше всего интересует, правильно ли я задаю эти вопросы. Итак, вот и все:

• Как при использовании реляционной базы данных вы гарантируете, что несколько потоков не будут мешать друг другу при записи в базу данных?
• Может ли наличие нескольких потоков, обращающихся к базе данных, создать ситуацию, при которой данные, которые они читают, не синхронизированы?
• Как мне управлять разрешениями на чтение / запись из базы данных?
• Есть ли вещи, которые не принадлежат базе данных (изображения, большие куски текста)?

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

Answer 1

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

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

http://www.sqlteam.com/article/introduction-to-transactions

Что касается того, «что не принадлежит в базе данных», то изображения и большие куски текста в порядке. Вы можете хранить двоичные двоичные объекты, вы можете хранить код, если это имеет смысл для того, что вы делаете. Единственное, что я хотел бы предложить, - это подумать о том, в ваших ли интересах непосредственное хранение изображений в БД или сохранение путей / имен файлов для файлов, находящихся на вашем сервере.

Answer 2

что я должен делать для обеспечения одновременного доступа

Вы позволяете базе данных справиться с этим, для чего она и предназначена.

---

• Как при использовании реляционной базы данных вы гарантируете, что несколько потоков не будут мешать друг другу при записи в базу данных?

База данных справится с этим. Иногда это будет означать, что один из запросов будет прерван во избежание тупика. Вы должны обнаружить это в своем коде.

• Может ли наличие нескольких потоков, обращающихся к базе данных, создать ситуацию, в которой данные, которые они читают, не синхронизированы?

Да, это возможно. С этим мало что можно сделать - это следствие того, что несколько потоков читают / записывают одни и те же данные. Есть команды синхронизации, которые вы можете использовать, но они могут повлиять на производительность.

• Как мне управлять разрешениями на чтение / запись из базы данных?

Через механизм безопасности базы данных, какими бы они ни были.

• Есть ли вещи, которые не принадлежат базе данных (изображения, большие куски текста)?

Большие файлы, хотя даже это зависит от приложения. Храните данные приложения в вашей базе данных.

Answer 3

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

Это дает дополнительное преимущество, позволяя мне масштабировать, добавляя больше оборудования среднего уровня.