Соображения при хранении нескольких длинных текстов в базе данных с php и MySQL

Question

Я создаю веб-сайт и плохо знаком с php и mysql.Я только что прочитал столько, сколько мог, этим утром, и у меня все работает при регистрации и входе в систему вместе с формой, которую пользователь может использовать для отправки контента.

Мой вопрос, в частности, заключается в том, как хранить пользователяпредставленный контент.Содержание будет в основном статьями.В настоящее время у меня есть база данных для всех пользователей, в которой хранятся их имена, идентификаторы и пароли, но всякий раз, когда кто-то создает учетную запись, я создаю новую базу данных вместе с ними для хранения любых статей, которые они отправляют.Есть ли проблемы с этим?Мне не нужно, чтобы статьи были доступны для поиска на этом этапе, но я хотел бы сохранить текст статей, категорию, в которую попадает статья, и время ее публикации.

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

Answer 1

Я был разработчиком CMS-эксклюзива в течение 5 лет, поэтому я прыгал через те же обручи.

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

В своей личной работе я предпочитаю использовать только одну базу данных и добавлять поле идентификатора пользователя или компании в каждую запись.Таким образом, если по какой-то причине я хочу объединить данные из одного аккаунта в другой, это будет просто.Попытка поиска по БД определенно не будет веселой задачей.Основное поле содержимого (тело, содержимое и т. Д.) Почти всегда является текстовым полем MySQL, чтобы избежать исчерпания пространства.Убедитесь, что при вставке вы делаете какую-то очистку данных, чтобы избежать внедрения SQL.Mysql_real_escape_string обычно делает свое дело.

Космически, если вы не вырастите ОЧЕНЬ популярный сайт, у вас не будет проблем.Я запустил несколько сотен CMS среднего размера на одном маленьком сервере без проблем.

Answer 2

При использовании баз данных основной проблемой является SQL-инъекция . Используйте параметризованные запросы или экранируйте все свои данные. Также в таблице пользователей не храните простой текстовый пароль. Используйте хеш и соль.

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

Answer 3

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

Что вы должны (вероятно) сделать, это создать таблицу статей, которая содержит статьи (заголовок, контент и т. Д.), И таблицу пользователей, содержащую пользовательские данные. В зависимости от вашей модели данных вы можете хранить данные об авторах в строке db для каждой статьи (внешний ключ), или в случае, если в одной статье может быть несколько авторов, соединения (отношения) можно хранить в отдельной таблице.