2015-05-05 5 views
-1

Это то, что у меня есть:Daily Time Schedule (MySQL)

days_of_week 
+----+-------------------+ 
| id | name    | 
+----+-------------------+ 
| 1 | Monday   | 
| 2 | Tuesday   | 
| 3 | Wednesday   | 
| 4 | Thursday   | 
| 5 | Friday   | 
| 6 | Satday   | 
| 7 | Sunday   | 
+----+-------------------+ 

time 
+----------+-------------+ 
| id  | time  | 
+----------+-------------+ 
| Integer | hh:mm:ss | 
+----+-------------------+ 

schedule 
+---------+---------+----------+---------+ 
| id  | user_id | time_id | day_id | 
+---------+---------+----------+---------+ 
| Integer | Integer | Integer | Integer | 
+---------+---------+----------+---------+ 

Где я должен поставить колонку активности, т.е. завтрак 08:30, например. Теперь «Завтрак» нужно хранить где-то здесь. Я не могу понять, где на данный момент, но если кто-то знает, как правильно нормализовать это, пожалуйста, поделитесь со мной и расскажите, почему вы так делаете или рекомендуете это. Заранее большое спасибо.

То, что я хочу добиться:

Monday: Date of that day here 
08:00 Breakfast 
08:30 Something else 
09:00 Introduction 

Tuesday: Date of that day here 
08:00 Breakfast 
09:00 Hackathon begins 
12:30 Lunch 

Вы получаете его.

Для уточнения:

Пользователь может выбрать, чтобы добавить расписание, это расписание будет создано и включает в себя график для того, что будет происходить в те определенные дни, например, если есть Hackathon происходит для 3 дня пользователь может создать расписание для этих трех дней, со временем и активностью. Например. 8:00 Завтрак, 09:00 Введение, 9:30 Установка оборудования

Нашел: Очень нормализуется, Method for storing/displaying repeating weekly schedule

Однако, это больше для повторения недельного графика, который не то, что я хочу достичь.

+0

Ха-ха! Конечно, я человек, который его проектирует. Тем не менее, я все еще не уверен, где разместить материал активности, или должен быть в отдельной таблице, а затем связан с таблицей расписания? –

+0

"заключается в том, что вам не нужны первые две таблицы", это не имеет смысла. Подумайте о ремонтопригодности в долгосрочной перспективе. –

+0

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

ответ

1

Вы собираетесь провести повторяющуюся неделю по расписанию?

Если нет, я бы подумал о том, чтобы отбросить дни недели и таблицы времени и использовать стандартное поле DATETIME. Вы можете применять любые ограничительные меры при проверке модели, и это может также облегчить обнаружение конфликтов.

Вы хотите регулярно повторять действия?

Если это так, я бы сделал таблицу действий и ссылаюсь на это по расписанию.

Если нет, я бы, вероятно, согласился на описание и время.

SIMPLE

  • Расписания (идентификатор, описание, дата и время)

повторяемой ДЕЯТЕЛЬНОСТЬ

  • Расписание (идентификатор, activity_id, дата и время)
  • активности (id, descripti на)

НЕДЕЛИ НА НЕДЕЛЮ ГРАФИК (ж/повторяемых деятельности)

  • Schedule (идентификатор, activity_id, day_of_week_id, время)
  • активность (идентификатор, описание)
  • DAY_OF_WEEK (id, заголовок)

Всегда выбирайте самый простой вариант, который вас выполняет r требования!

+1

Это не похоже на школьное расписание (которое почти) повторяется каждую неделю. Это график по сборке один раз, и как только эти дни закончится, вы перейдете к следующему разу. Активность (например, завтрак и т. Д.) Добавляется вручную, и пользователь может вручную вводить их на любом языке. Спасибо за ответ с ответом. –

+0

@JohnSmith Это все еще не очень объяснение, но это как минимум. Предложите вам соответствующим образом изменить свой вопрос. – Strawberry

+0

@Strawberry I обновлен, пожалуйста, прочитайте сейчас. –

1

Нормализовать! Поскольку вы уже это делаете:

// others omitted 
activity(id, description) 
day(id, time_id, activity_id) 
schedule(id, day_id) 

Я мог бы что-то пропустить, но открыть для исправления.

+0

Я думаю, что полная нормализация - это путь, ведь я нашел пример, за исключением того, что это связано с чем-то, но они нормализовались до 4 таблиц. –

+1

Thats great, я думаю, что вы уже/почти там. Просто нужно идентифицировать сущности, а затем только нормализовать или удалить избыточные сущности. От 2 до 3 ненормальной формы достаточно хорошо, учитывая отношения, если только это не очень сложно. Но ваша схема движется вправо с несколькими настройками. Нет никакого вреда, чтобы иметь больше таблиц, чтобы избежать избыточных данных. Надеюсь это поможет. – daxeh