Итак, у меня есть набор данных, представляющих объекты шара. Каждый шар предопределен, т. Е. Существует количество объектов шара, скажем, 3 всего. Каждый шар имеет имя (строка). Каждый шар может быть либо малым, средним, либо большим (перечисление) и может быть либо зеленым, либо красным (перечисление). Для каждого шара каждого типа каждого цвета я хочу иметь историю последних 10 мест (произвольный тип для этого примера).ASP Как организовать базу данных, где каждый элемент имеет несколько известных значений?
Таким образом, на начальном этапе, моя мысль была создать таблицу шара объектов следующим образом:
public class Ball {
public int Id { get; set; }
public string Name { get; set; }
public Color Color { get; set; }
public Size Size { get; set; }
public virtual ICollection<BallHistory> History { get; set; }
}
public class BallHistory {
public int Id { get; set; }
public DateTime Date { get; set; }
public int BallId { get; set; }
public virtual Ball Ball { get; set; }
}
Однако, это означает, что у меня будет много повторов шариковых данных (например, имя), потому что Имя будет повторяться для каждого размера и каждого цвета, как показано на следующем:
Ball Table:
Id Name Color Size
0 MyBall 0 0
1 MyBall 0 1
2 MyBall 0 2
3 MyBall 1 0
4 MyBall 1 1
5 MyBall 1 2
History Table:
10 items with BallId = 0,
10 items with BallId = 1,
etc.
Теперь, из-за того, как классы создаются, таблица истории будет содержать 10 записей для каждого шара, где каждая запись хранит Id для Ball это история. Проблема заключается в том, как лучше всего создавать классы для минимизации избыточных данных. Поскольку оба цвета и размер предварительно определены, мне было интересно, как лучше всего разделить эти данные на свою собственную таблицу, если это возможно. Примером может быть дублирование свойства History в Ball, так что существовала SmallHistory, MiddleHistory и LargeHistory. Или, может быть, лучше каким-то образом выделить цвет и размер, а вместо повторения свойства Name будет повторяться только целое число для каждого разного цвета и размера (что будет меньше данных).
Есть ли мысли по этому поводу? Если что-то потребует больше разъяснений, дайте мне знать. В этом примере есть 3 шара, каждый из которых имеет 2 варианта цвета и 3 размера (всего 6 вариантов), а для каждого конкретного шара с конкретными опциями есть 10 предметов истории. Итак, в этом примере в таблице Ball есть 18 строк и 180 строк в таблице BallHistory, если я не ошибаюсь. В моем реальном приложении количество шаров будет около 1000, с 7 цветами и 2 вариантами размера, так что в общей сложности 14 000 уникальных мячей, каждый с 10 записями истории, в общей сложности 140 000 записей истории. Конечно, если сделать так, как указано выше, это много повторений свойства Name.
Выглядит хорошо. Если вы действительно хотите избежать дублирования имен, вы можете создать таблицу Ball с идентификатором и именем и связать BallId с цветом и размером в другой таблице. – Shyju
Не могли бы вы иметь только идентификатор мяча в таблице истории и ссылаться на таблицу Ball, если вам нужно имя? – Laslos
@Shyju Я просто чувствовал, что было не очень удобно хранить то же точное имя 14 раз. Тем более, что в моем приложении больше данных, чем в этом примере. Как я мог бы оптимально разбить его, зная возможные значения для цвета и размера? – John