Stockage de matrices dans une base de données relationnelle

Je suis en train de travailler sur un projet pour un client et en passant par la base de données initiale de conception. Le projet consistera en une simple application web pour le suivi des processus et de leurs résultats dans un diagramme matriciel, je suis à la recherche d'un bon moyen de stocker ces informations dans des tables relationnelles.

Droit maintenant, je pense que j'ai un tableau général des Routines qui le x et le y coords sera la carte aussi, et peut-être par une table contenant l'ID de coordonnées dans lequel un "hit" est enregistré. N'importe qui ont des meilleures façons de faire ça?

Merci!

EDIT:

Ce n'est que le début du projet, j'ai donc peu de détails pour l'instant, mais mon principal raisonnement à l'origine de plusieurs tables est parce que les matrices seront complètement dynamique dans la taille et génériques, de sorte que chacun peut être différent et ils seront liés à un utilisateur

J'ai aussi oublié de mentionner que l'ordre de x/y, les valeurs sont importantes, ce qui a soutenu mon raisonnement derrière le fait d'avoir plusieurs tables pour x, y et les valeurs, de ce que je suppose que le besoin de connaître chaque cellule est important

EXEMPLE:

L'exemple de base (quoique abrégé) de ce phénomène réside dans le processus relatif à un restaurant. Les actions de choses le long des lignes de vous asseoir, commander de la nourriture, regardez sur menu, des boissons, de manger, de payer, etc. les résultats en cours de prise de commande, des boissons livrés, aliments, changement donné. Bien qu'apparemment simple, il devient complexe lorsqu'il est pris en considération les choses se passent différemment avec chaque occurrence, dans le cas de la prendre ou de buffets. l'ordre des actions et des résultats devient partie intégrante de voir les différences entre les situations

source d'informationauteur Jimmy

  1. 19

    Il y a beaucoup de façon de le faire, nous aurions besoin de beaucoup plus d'informations pour être plus précis sur ce qui serait le mieux pour vous. Cependant, ici, sont les deux SOP façons:

    Soit un tableau distinct pour chaque matrice:

    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

    Ou, toutes les matrices dans un tableau:

    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

    Ce sont standard forme normale, pratiquement toutes les autres façons de le faire ne sont pas normalisées. Certains avantages de ces approches:

    1. Vous n'avez pas à remplir dans chaque cellule, seulement ceux que vous utilisez. Ou avoir une valeur par défaut (0 ou "") et d'ignorer ceux.
    2. C'est de loin l'approche la plus souple, même dans le "tout en un" modèle, il n'est pas nécessaire de les limiter à la même taille en aucune façon, et il est très facile de les redimensionner.
    3. Vous pouvez facilement effectuer une requête sur la contenu de la matrice, quelque chose qui est de plus en plus difficile dans un stockage plus compact méthodes.
    4. "Hit"s ou de tout autre aspect des cellules de la matrice sont faciles à mettre en œuvre que des champs supplémentaires dans les lignes. Rendre Null-mesure si vous êtes inquiet au sujet de l'espace supplémentaire et d'index si vous le souhaitez, à la requête d'un rapport sur ces attributs séparément. Son aussi facile que de rénovation des caractéristiques comme cela avec ce modèle aussi.

    Le principal inconvénient est qu'il existe généralement une grande espace pour les données de surcharge. Nombreux sont ceux qui croient qu'il est aussi haut dans le ciel pour Insérer ou d'extraire de nouvelles matrices, mais en fait il y a plusieurs techniques documentées, ce qui peut rendre très vite.

  2. 4

    Est votre matrice dense de éparses? Si c'est incomplet, il peut être préférable, pour chaque entrée à enregistrer dans une liste de hit, plutôt que d'avoir un full 2D table qui est la plupart du temps 0.

  3. 3

    Plutôt que deux tables, je voudrais juste utiliser un tableau: (x, y, résultat). Au-delà de qu'il est difficile de donner plus de conseils, avec le peu de renseignements donnés.

  4. 2

    De mémoire vidéo, très simple 2D matrice est stockée comme suit:

    ABCD
EFGH
IJKL

    dans la ram de manière séquentielle comme un tableau comme

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

    élément x,y peuvent être trouvés à la matrice de décalage 

    [y*width+x]

    par exemple, x=2,y=2 (de base zéro) fait référence à l'élément de K.

    [y*width+x]=[2*4+2]=10. élément du tableau 10 (encore une fois à zéro) = K, de sorte que vous êtes bon.

    Stocker dans une liste délimitée par des virgules vous permettra de déposer une matrice de taille quelconque dans un champ de type nvarchar. Cette suppose que vous n'avez pas besoin d'interroger des cellules individuelles dans SQLmais il suffit de saisir la matrice comme un tout et les traiter à côté client.

    Votre table peut ressembler à ceci:

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

    Aussi, cela fonctionne très bien si vous êtes matrices sont rares, sinon vous vous retrouverez avec beaucoup de vide ,,,,, éléments. Vous pouvez contourner ce aussi bien, bien.