2012-03-14 2 views
0

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

Тем не менее, будут проходить бессрочные раунды соревнований, поэтому я хочу сохранить Round # в столбце в DataBase. Другое требование состоит в том, что у каждого раунда есть своя собственная информация, поэтому я буду делать вторую таблицу с Round_Number, затем другие поля, такие как Описание, Дата погашения и т. Д.

Итак, это моя текущая идея схемы БД:

Entries (Comp #, Entry # AutoInc, Password, 
    Entry Date, Author Contact, Description, Screenshot, Website) 
Competitions (Comp #, Theme, Entries, Start Date, Finish Date, Prize) 

Таким образом, записи могут вступить в Соревнования на Comp #, чтобы получить дополнительную информацию о его конкурсе. Являются ли они наиболее эффективными? Нет учетной записи (или таблицы пользователей), каждая запись просто получает свой собственный пароль для редактирования.

+0

Может ли одна запись иметь более одного конкурса? Я предполагаю, что да. Может ли один конкурс быть для нескольких записей? Я предполагаю, что нет. Если мои предположения верны, я бы удалил Comp # из таблицы «Записи» и изменил Записи в таблице «Соревнования» на «Ввод». –

+0

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

+0

О, ладно ... так что «Записи» - это раунды. Если это так, структура выглядит хорошо для меня. –

ответ

0

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

CREATE TABLE USERS_T ( account_id number, username varchar, password data_type, author varchar, .... )

CREATE TABLE COMPETITIONS_T ( comp_id number, description varchar, theme varchar, #entries number- not needed, just count by id in ENTRIES_T table start_date date, finish_date date, prize varchar, ... )

CREATE TABLE ENTRIES_T ( account_id number, comp_id number, entry_date date, descr varchar, screenshot blob, website varchar, ... )

Каждое соревнование может иметь несколько записей, но каждая запись может быть только 1 конкуренции.

Добавьте первичный ключ на столе ENTRIES_T: PRIMARY KEY (account_id, comp_id)

Вы могли бы даже принять это дальше, определить темы таблицы, комментарии таблицы и т.д. Я думаю, вы получите идею. Надеюсь это поможет. Удачи!

+0

Это хорошая идея хранить скрины как капли? Как я могу их вывести? Есть ли преимущество над сохранением URL-адреса на скриншоте? – DanRedux

+0

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

+0

Это правда. Мне просто интересно, есть ли преимущества для приема загруженных изображений и их локального хранения в виде файлов или как капли. Файлы проще для сервера, я знаю это точно, но я думаю, что blobs могут быть более безопасными? – DanRedux