#mysql
#mysql
Вопрос:
в настоящее время я работаю над проектом, который, на первый взгляд, потребует большого количества таблиц в базе данных. Большинство таблиц довольно просты, однако у меня есть проблема. Одна из таблиц будет представлять собой список участников веб-сайта, в который будут включены такие данные, как имя пользователя, пароль, контактная информация, биография, образование и т.д. Это простой дизайн, однако также необходимо, чтобы каждый участник вводил свою доступность и также сохранял ее в базе данных. Доступность определяется как диапазон дат и времени. Например, доступно 5.04.2011 с 13:00 до 18:00 по восточному времени или недоступно каждую пятницу после 8:00 по восточному времени. Для одного пользователя это может быть отдельная таблица, но для многих пользователей я не уверен, как организовать данные управляемым образом. Первой мыслью было бы иметь код для создания таблицы для каждого пользователя, но это может означать множество таблиц в базе данных в дополнение к тем немногим, которые у меня есть для других функций сайта. Логически я мог бы использовать имя пользователя, добавленное к Avail_ или что-то в этом роде, для имени таблицы, т. е.: Avail_UserBob, а затем запрашивать это по мере необходимости. Но мне любопытно, может ли кто-нибудь придумать вариант получше, чем иметь потенциал сотен таблиц в одной базе данных.
редактировать Таким образом, общим соглашением было бы иметь таблицу для участников, например, уникальный ключ, являющийся ID. Затем создайте вторую таблицу доступности (дата, время начала, время окончания, логическое значение для доступно или нет, и идентификатор участника, к которому это относится). Django может звучать красиво и хорошо работать, но у меня нет времени тратить на изучение другого фреймворка во время работы над этим проектом. Метод 2 таблиц кажется правдоподобным, но меня беспокоит дополнительное кодирование, необходимое для функций, которые будут использовать время доступности для А) создания страницы, подобной календарю, для добавления, редактирования или удаления введенных значений, и Б) сопоставления доступности с записями из другой таблицы, в которой перечислены игры. Хотя у меня могло бы быть больше кода, я могу смириться с этим, пока база данных надежна, функциональна и не так запутана. Спасибо за информацию, ребята.
Комментарии:
1. Вам также следует создать новую копию программы для каждого пользователя.
Ответ №1:
Не хочу показаться троллем, но вам следует взглянуть на использование веб-фреймворка для создания большей части этого для вас. Я бы посоветовал взглянуть на Django. С его помощью вы можете определить тип полей, которые вы хотите сохранить (и как они связаны), и Django создает все инструкции SQL, чтобы сделать это так. Вы получаете приятный интерфейс администратора бесплатно, чтобы сотрудники могли входить в систему и добавлять / редактировать / etc.
Вам также не нужно беспокоиться о создании форм входа / авторизации / смены пароля и т.д. обо всех этих сеансовых вещах заботится Django. Вы можете сосредоточиться на том, что делает ваш проект / приложение уникальным.
И это позволяет вам создавать свой проект очень, очень быстро.
djangoproject.org
У меня нет никаких других предложений по фреймворку, которые отвечали бы вашим потребностям. Я делаю … но я думаю, что Django подойдет по всем параметрам.
Комментарии:
1. Отлично! Вот как я решал эту проблему, снова и снова с каждым из моих клиентов. Я чувствую себя так, как будто я должен быть продавцом Django или кем-то в этом роде. Но на самом деле… это отличный фреймворк. Я ни черта не знал о Python, когда только начинал. Итак, мои шаблоны содержали МНОГО logic…as Я стал лучше разбираться в Python, я продвинул свою логику дальше в представления, методы модели, менеджеры и т.д. Теперь я str8 pimpin. Этот парень тоже мог бы быть таким.
Ответ №2:
Создайте таблицу для хранения пользователей. Используйте ее первичный ключ в качестве внешнего ключа в других таблицах.
Ответ №3:
Базы данных написаны так, чтобы содержать много-много строк в таблице. Не оптимизирован для создания таблиц. Поэтому создавать новую таблицу для каждого пользователя — не очень хорошая идея. Вместо этого дайте каждому пользователю уникальный идентификатор и поместите доступность в отдельную таблицу. Предоставьте дополнительный флаг, чтобы сделать запись действительной или недействительной.
Ответ №4:
Создайте таблицу пользователей; затем создайте таблицу доступности для каждого пользователя. Не пытайтесь втиснуть возможности доступности в таблицу user: это впоследствии принесет вам огромные огорчения; и вы обнаружите, что тогда вам придется создать таблицу доступности.
Погуглите нормализацию базы данных, чтобы понять, почему.
Примите это как правду от того, кто перенес такое горе, причиненное самому себе 🙂