Вопрос:

Представление фиксированного числа повторяющихся независимых объектов в таблице SQL

sql sql-server

51 просмотра

3 ответа

56 Репутация автора

Я пытаюсь представить объект с четырьмя независимыми точками (и множеством других свойств, представленных здесь [...]) в SQL. Подход с одной таблицей может выглядеть так:

CREATE TABLE Object (
    Id bigint NOT NULL IDENTITY(1,1) PRIMARY KEY,
    [...]
    Point1X float NOT NULL,
    Point1Y float NOT NULL,
    Point2X float NOT NULL,
    Point2Y float NOT NULL,
    Point3X float NOT NULL,
    Point3Y float NOT NULL,
    Point4X float NOT NULL,
    Point4Y float NOT NULL
)

Где многостоловый подход может выглядеть так:

CREATE TABLE Object (
    Id bigint NOT NULL IDENTITY(1,1) PRIMARY KEY,
    [...]
    Point1 bigint NOT NULL FOREIGN KEY REFERENCES Point(Id),
    Point2 bigint NOT NULL FOREIGN KEY REFERENCES Point(Id),
    Point3 bigint NOT NULL FOREIGN KEY REFERENCES Point(Id),
    Point4 bigint NOT NULL FOREIGN KEY REFERENCES Point(Id)
)

CREATE TABLE Point (
    Id bigint NOT NULL IDENTITY(1,1) PRIMARY KEY,
    XCoord float NOT NULL,
    YCoord float NOT NULL
)

Второй подход выглядит гораздо более элегантно, если исходить из опыта проектирования ОО, но в то же время я уже вижу, как будет немного сложнее работать при обновлении рассматриваемых объектов в моем ORM, и мне не нравится количество ограничений FK я добавляю. Первый вариант выглядит очень загроможденным, и это также означает, что я не смогу добавить другие свойства к точкам после факта (скажем, если я хотел назначить a Colorдля каждой точки через шесть месяцев).

Я также сказал бы, что есть третий вариант, где Pointsтаблица сохраняет ссылку на внешний ключ обратно на Object, что означает, что объект может теперь иметь любое количество точек. Мне не очень нравится этот вариант. Для текущей области проекта у объекта всегда будет ровно четыре точки, так что с этим ограничением придется столкнуться на моем прикладном уровне, и это еще более затруднит работу с отношением внутри ORM.

Как правильно разработать такой дизайн?


РЕДАКТИРОВАТЬ: Еще несколько деталей:

  • Точки представляют среднюю точку каждой стороны прямоугольника - представьте крестообразную форму.
  • Важно знать, какие точки находятся напротив друг друга - следовательно, есть определенный центр или какой-то порядок (например, точка 1 всегда находится прямо напротив точки 3).
  • Помимо вышеуказанного ограничения, здесь нет упорядочения точек.
  • На данный момент я буду только запрашивать объекты, а затем рисовать их точки, а не выполнять запросы к самим точкам, хотя я мог бы видеть, что это требование в будущем.
  • Объекты не должны перекрываться, но это не является жестким ограничением в системе.
  • Объекты также не должны иметь одинаковые четыре точки. Так как точки являются плавающими (по крайней мере, в этом примере - я открыт для лучших предложений для типов данных) и первоначально взяты из пользовательского ввода (думаю, позиции курсора мыши на холсте), я не думаю, что очень вероятно, что любые два объекты будут когда-либо разделять любые пункты.
Автор: Chris D. Источник Размещён: 22.08.2016 08:23

Ответы (3)


0 плюса

876751 Репутация автора

Это не редкое дизайнерское решение.

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

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

Автор: Gordon Linoff Размещён: 22.08.2016 08:31

0 плюса

10904 Репутация автора

CREATE TABLE Object (
    Id bigint NOT NULL IDENTITY(1,1) PRIMARY KEY,
    [...]
)

CREATE TABLE Point (
    Id bigint NOT NULL IDENTITY(1,1) PRIMARY KEY,
    XCoord float NOT NULL,
    YCoord float NOT NULL
)

CREATE TABLE ObjectPointCrossRef (
    Id bigint NOT NULL IDENTITY(1,1) PRIMARY KEY,
    ,ObjectId bigint NOT NULL
    ,PointId bigint NOT NULL
)

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

Автор: Matt Размещён: 22.08.2016 08:45

0 плюса

6474 Репутация автора

Решение

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

У вас есть 3 потенциальных дизайна. Я позвоню им

  1. Одноместный стол
  2. Два стола
  3. Три таблицы (ответ Мэтта).

Ключевыми факторами, на мой взгляд, являются:

  • Будет ли необходимость обобщать отношения между объектами и указывать на отношение от 1 до N? Будут ли отношения всегда от 1 до 4?
  • Будет ли необходимость работать с точками вне контекста объектов? Например, необходимо запросить все точки в заданном диапазоне?

Если ответом на эти 2 вопроса является «нет / нет», то я бы пошел с решением 1 и оставил композиционную модель в пространстве ОО, предоставив слою отображения ОО / БД задачу разложения графа объекта на 1 строку в 1 таблице. , Да, определения столбцов не выглядят элегантно, но как только таблица на месте, с ней все станет проще. Нет присоединений. Нет ФК. Нет возможности случайно создать объект только с 2 точками. С этим решением вы, вероятно, получите лучшую производительность.

Если ответ на любой из приведенных выше вопросов положительный, я бы выбрал вариант № 3, хотя я думаю, что таблице ассоциаций необходимо другое поле, чтобы указать, как точка относится к объекту (т. Е. Точка № 1 / № 3 или точка № 2 /). # 4). Без сомнения, Мэтт не знал об этом требовании, когда разрабатывал свой ответ.

Автор: Aheho Размещён: 23.08.2016 03:28
Вопросы из категории :
32x32