Хранение матриц в реляционной базе данных

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

Прямо сейчас я думаю, что у меня есть общая таблица для Routines, которые координаты x и y также будут отображаться и, возможно, выключены из таблицы поиска, содержащей идентификатор координат, в котором записывается "хит". У кого-нибудь есть лучший способ сделать это?

Спасибо!

EDIT:

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

Я также забыл упомянуть, что порядок значений x/y важен, что еще больше подтвердило мои рассуждения о том, что у меня есть несколько таблиц для xy и значений, из этого я решительно полагаю, что важно знать каждую отдельную ячейку.

Пример:

Основной пример (хотя и абстрактный) заключается в том, что касается ресторана. Действия, которые происходят по линиям сидения, заказывают еду, просматривают меню, заказывают напитки, едят, платят и т.д., Результаты принимаются, принимаются напитки, доставляются продукты, изменяются данные. Несмотря на кажущееся простое, он становится сложным, если принять во внимание, что все происходит по-разному с каждым случаем, также в случае вывоза или буфетов. порядок действий и результатов становится неотъемлемой частью различий между ситуациями

Ответы

Ответ 1

Есть много способов сделать это, нам потребуется гораздо больше информации, чтобы быть более конкретным о том, что было бы лучше для вас. Однако вот два способа SOP:

Либо отдельная таблица для каждой матрицы:

CREATE TABLE YourMatrixName(
    RowNo smallint NOT NULL,
    ColNo smallint NOT NULL,
    CellValue varchar](50) NULL,
 CONSTRAINT [PK_Matrices] PRIMARY KEY CLUSTERED 
    ([RowNo] ASC, [ColNo] ASC)
) ON [PRIMARY];
GO

CREATE UNIQUE NONCLUSTERED INDEX IX_YourMatrixName ON dbo.YourMatrixName
    (ColNo, RowNo); 
GO

Или все матрицы в одной таблице:

CREATE TABLE Matrices(
    MatrixName varchar(24) NOT NULL,
    RowNo smallint NOT NULL,
    ColNo smallint NOT NULL,
    CellValue varchar(50) NULL,
 CONSTRAINT [PK_Matrices] PRIMARY KEY CLUSTERED 
    ([MatrixName] ASC, [RowNo] ASC, [ColNo] ASC)
) ON [PRIMARY];
GO

CREATE UNIQUE NONCLUSTERED INDEX IX_Matrices ON dbo.Matrices
    (ColNo, RowNo); 
GO

Это стандартная нормальная форма, практически все другие способы ее выполнения плохо нормализованы. Некоторые преимущества этих подходов:

  • Вам не нужно заполнять каждую ячейку, только те, которые вы используете. Или введите значение по умолчанию (0 или "") и пропустите те.
  • Это самый гибкий подход, даже в модели "все в одном", нет необходимости каким-либо образом ограничивать их до одного размера, и их очень легко изменить.
  • Вы можете легко запросить содержимое матрицы, что становится все труднее при использовании более компактных методов хранения.
  • "Хит" или любой другой аспект ячеек матрицы легко реализовать в виде дополнительных полей в строках. Сделайте их Null -способными, если вас беспокоит дополнительное пространство, и проиндексируйте их, если вы хотите запросить/сообщить об этих атрибутах отдельно. Его также так же легко модифицировать такие функции с этой моделью.

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

Ответ 2

Является ли ваша матрица плотной редкой? Если он разрежен, для каждой записи может быть лучше просто сохранить список хитов, а не иметь полную 2D-таблицу, которая в основном равна 0.

Ответ 3

Вместо двух таблиц я бы просто использовал одну таблицу: (x, y, result). Кроме того, трудно дать больше советов с ограниченной информацией.

Ответ 4

Видеопамять, очень простая 2D-матрица сохраняется следующим образом:

ABCD
EFGH
IJKL

в ram последовательно, как массив, как

A,B,C,D,E,F,G,H,I,J,K,L

элемент x, y можно найти при смещении массива

[y*width+x]

например, x = 2, y = 2 (основанный на нуле) относится к элементу K.

[y*width+x]=[2*4+2]=10. элемент массива 10 (опять же основанный на нуле) = K, поэтому вы хорошо.

Сохранение в списке с разделителями-запятыми позволит вам поместить матрицу любого размера в поле nvarchar. Этот предполагает, что вам не нужно запрашивать отдельные ячейки в SQL, но просто возьмите матрицу в целом и обработайте ее на стороне клиента.

Ваша таблица может выглядеть так:

tbl_matrices
----
id
user_id
matrix nvarchar(max)

Кроме того, это очень хорошо работает, если вы матрицы разрежены, иначе вы получите множество пустых элементов,,,. Однако вы можете обойти это и.