Вопросы Теги

Дизайн схемы для того, когда пользователи могут определить поля

Ваш код не будет работать - перечисления не совсем классы: 

@unique
class MyEnum(Enum):
    ONE = 1
    TWO = 2
    THREE = 3
    FOUR = 4

@unique
class MyTrySubset(Enum):
    pass
blockquote> 
 for item in MyEnum: 
    setattr(MyTrySubset, item.name,     item.value)  # no duplication error by @unique
    setattr(MyTrySubset, item.name+"a", item.value)  # no duplication error by @unique

for s in MyTrySubset:
    print(s)           # no output - at all

for s in MyEnum:
    print(s)           # prints all repr() of all Enum-values defined

Используйте другое перечисление для объявления этого (не будет сравнивайте, хотя:): 

@unique
class MyDesiredSubset(Enum):
    THREE = MyEnum.THREE
    FOUR = MyEnum.FOUR

или используйте свободный подход: 

MyOther = Enum("MyOther", [(a.name,a.value) for a in MyEnum 
                           if a in [MyEnum.THREE,MyEnum.FOUR]] )

Если вы используете вместо этого IntEnum , вы даже можете сравнить их: [ 1110] 

@unique
class MyIntEnum(IntEnum):
    ONE = 1
    TWO = 2
    THREE = 3
    FOUR = 4

@unique
class MyDesiredIntSubset(IntEnum):
    THREE = MyIntEnum.THREE
    FOUR = MyIntEnum.FOUR

print(MyDesiredSubset.THREE == MyEnum.THREE)       # False
print(MyDesiredIntSubset.THREE == MyIntEnum.THREE) # True 
print(MyDesiredIntSubset.THREE == 3)               # True @Steven Rumbalski

5
задан Eli 9 January 2009 в 19:55
поделиться

4 ответа

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

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

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

Вот немного измененная версия схемы, которую Вы предоставили. Я предполагаю, что можно выяснить, какие типы данных идут где :-)

    surveys
      survey_id (index)
      title

    questions
      question_id (index, auto increment)
      survey_id (link to surveys->survey_id)
      question

    responses
      response_id (index, auto increment)
      survey_id (link to surveys->survey_id)
      submit_time

    answers
      answer_id (index, auto increment)
      question_id (link to questions-question_id)
      answer
5
ответ дан 14 December 2019 в 09:03
поделиться

Я предложил бы, чтобы Вы всегда проявили нормализованный подход к своей схеме базы данных и затем позже решенный, если необходимо создать решение по причинам производительности. Преждевременная оптимизация может быть опасной. Преждевременная денормализация базы данных может иметь катастрофические последствия!

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

1
ответ дан 14 December 2019 в 09:03
поделиться

Одно изменение, которое может или не может помочь упростить вещи, не состояло бы в том, чтобы связать ResponseAnswers назад с SurveyID. Скорее создайте идентификатор на ответ и на вопрос и позвольте своей таблице ResponseAnswers содержать поля ResponseID, QuestionID, Ответ. Хотя это потребовало бы уникальных идентификаторов хранения для каждой единицы, она поможет сохранить вещи нормализованными. Ответы ответа не делают никакой потребности связаться с обзором, они отвечали просто на конкретный вопрос, на который они отвечают и информация об ответе, что они связаны.

1
ответ дан 14 December 2019 в 09:03
поделиться

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

Несколько незначительных различий:

  • Обзоры НЕ были анонимными, и это было сделано очень ясным в печатных формах. Это также означало, что демографические данные в Вашем примере были известны заранее.

  • Был пул вопросов, которые были присоединены к обзорам, таким образом, один вопрос мог использоваться на нескольких обзорах и анализироваться независимо от обзора, это появилось на.

  • Обработка различных типов вопросов стала интересной - у нас был масштаб 1-3 (например, Worse/Same/Better), масштаб 1-5 (Очень Плохо, Плохо, хорошо, Хороший, Очень Хороший), Да/Нет, и Комментарии.

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

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

0
ответ дан 14 December 2019 в 09:03
поделиться
Другие вопросы по тегам:

Похожие вопросы: