Какую схему я могу использовать для размещения ручных записей данных на основе даты?

У меня есть админ, где пользователи из нескольких свойств могут вводить ежемесячную статистику для подписчиков Twitter / Facebook. У нас нет доступа к реальным данным / db, поэтому вот почему ручная запись. Форма выглядит так:

Type ( radio, select **one** only ): - Twitter - Facebook Followers/Fans ( textfield ): Property (dropdown): Hotel A, Hotel B Date Start: mm/dd/yyyy (textfield) Date End: mm/dd/yyyy (textfield) 

Вопрос 1.1 : Поскольку я отслеживаю только месяц в месяц, поля начала и окончания даты, которые я уже создал, могут быть слишком конкретными. Было бы лучше, если бы только месяц начала / месяц и месяц / год, если это единственное, что меня волнует?

Вопрос 1.2 . Какую схему я мог бы использовать для статистических отчетов за месяц, чтобы изменить начальные и конечные текстовые поля даты, чтобы начать раскрывать свои данные за месяц / год и конец месяца / года?

Прежде всего, вы разрабатываете приложение backassward. Данные управляют пользовательским интерфейсом, а не наоборот.

это не имеет значения, если у вас есть выпадающие списки месяца / года или нет. ЧТО ВАМ НУЖНО КАРТИРОВАТЬ?

Если каждое значение за один месяц, то зачем беспокоиться о дате начала и окончания? Используйте одну дату и соглашение либо первого месяца, либо последнего месяца.

6/1/2010 – запись в ИЮНЕ 2010. День не имеет значения. Не используйте ничего, кроме типа даты.

Если вы нормализуете схему, вам нужна таблица для места в социальных сетях, таблица свойств, дочерняя таблица для обеих из них, у которой есть столбец даты для Count_for_month и целочисленный столбец для count_of_followers.

Ответ Марьяну

Ваши данные – единственное, что имеет значение. Если Excel исчезнет, ​​не волнует ли вас, если данные в файлах могут использоваться в Документах Google?

Но означает ли это, что я рекомендую собирать много ненужных данных? Или проектирование одного экрана за столом? (Я просто догадываюсь, что подразумевается под «таблицей и CRUD с центром»). Я также не говорю, что ваш datamodel не зависит от требований, но представление о том, что OUTPUT является единственной причиной существования вашей системы, – безумие.