économie préférence de l'ordre dans SQL

Question

Je suis en train de voir quelle est la meilleure façon de gérer le scénario suivant

J'ai une table appelée, permet de dire l'utilisateur, et j'ai une table appelée éléments. Chaque utilisateur peut avoir plusieurs éléments ajoutés à son compte. J'ai une autre table, disons AssociateItem, qui maintient l'association entre l'utilisateur et les éléments. (liens UserID à ItemID). Un utilisateur peut avoir plusieurs éléments, de sorte qu'il existe une relation un à plusieurs entre l'utilisateur et les éléments. L'ordre dans lequel ces éléments sont affichés est important, et l'utilisateur change la commande à partir de l'interface utilisateur (un peu comme la file d'attente Netflix :)). J'ai donc besoin d'un moyen de sauvegarder la commande quelque part, disons la table de préférences. donc pour chaque utilisateur je peux sauvegarder l'ordre d'affichage. Je pensais à un XML simple pour enregistrer la commande. Disons que l'utilisateur a des éléments 1, 3 et 5 dans son compte, et l'ordre d'affichage est de 3, 5, 1. Je peux maintenir un xml et le changer à chaque fois que l'utilisateur change de préférence d'affichage

<order> 
<item>3</item> 
<item>5</item> 
<item>1</item> 
<order> 

Il semble maladroit façon de le faire. Je ne suis pas un expert en base de données. donc si quelqu'un peut donner une meilleure solution. je vais vraiment l'apprécier. Désolé si le scénario n'est pas très clair.

Answer 1

Vous pouvez ajouter un numéro de commande dans la table AssociateItem. Vous pouvez ensuite récupérer les articles commandés par ce numéro de commande.

par exemple.

TABLE AssociateItem(UserId, ItemId, SortNumber) 

SELECT * FROM User U 
INNER JOIN AssociateItem AI ON U.UserId = AI.UserID 
INNER JOIN Item I ON AI.ItemId = I.ItemId 
ORDER BY AI.SortNumber 

La partie désordre vient quand vous voulez déplacer les éléments autour comme vous voulez vous assurer que les numéros sont synchronisés.

Si SortNumber est un entier, alors vous aurez envie de mettre à jour tous les SortNumbers des éléments suivants au numéro + 1.

Vous pourrez peut-être tricher et éviter toutes ces mises à jour en utilisant des nombres réels et classer le nouvel article à mi-chemin entre le précédent et le prochain article SortNumbers.

par exemple. Si vous voulez insérer quelque chose à la position 2 de la séquence 0,1,2,3, vous pouvez lui attribuer le numéro 0.5 donnant 0, 0.5, 1, 2, 3

Si vous souhaitez ensuite insérer quelque chose de nouveau en position 2, vous pouvez lui attribuer 0,25 donnant 0, 0.25, 0.5, 1, 2, 3 etc. Il est évident que cette volonté arrêtez de travailler à un moment où vous n'avez pas assez de précision pour représenter le nombre correctement, mais cela devrait convenir aux petites listes.

Answer 2

Je considérerais une table de lien entre les deux articles et (je pense) c'est une approche assez standard de l'industrie.

Vous avez donc une table appelée "User" et une table appelée "Items". Vous voudrez créer une troisième table appelée quelque chose comme "UserItems".

Cette nouvelle table aura sa propre clé primaire mais contiendra deux clés étrangères; un à la table User et un à la table Items. Selon vos besoins, vous voudrez également ajouter une colonne pour stocker la priorité ou la séquence. Depuis le frontal, lorsqu'un utilisateur ajoute un élément et lui donne une priorité, il suffit d'ajouter une ligne dans la table UserItems. Réaffecter la priorité mettra à jour une ligne, etc., etc.

Answer 3

Deux points:

1) Pour répondre à votre question, vous pouvez enregistrer l'ordre dans la table d'association. Ajoutez un champ "OrderNumber" avec "userId" et "itemId". Maintenez ce champ comme vous avez fait allusion au xml. Il existe seulement quelques exemples spécifiques dans lesquels vous souhaitez conserver des données au format XML dans une application Web pilotée par SQL, et ce n'est pas le cas. Conservez cette information dans la base de données pour plus de cohérence et de rapidité.

2) Cela ressemble à une relation plusieurs-à-plusieurs, pas à une-à-plusieurs. Vous avez précisé qu'un utilisateur peut avoir plusieurs éléments, ce qui me dit que c'est l'une de ces options. La question restante est de savoir si un article peut appartenir à de nombreux clients? Si c'est le cas, c'est un nombre de many-to-many et vous avez besoin de la table AssociateItem. Si, toutefois, chaque élément ne peut appartenir qu'à un client, alors vous avez une relation un-à-plusieurs et vous n'avez pas besoin de la table AssociateItem. Au lieu de cela, ajoutez userId à la table des éléments et ajoutez également le nouveau champ "OrderNumber" directement à la table des éléments. Juste quelque chose à penser.

Answer 4

Ajoutez au tableau d'articles une colonne qui spécifie leur ordre. BTW, quel DBMS utilisez-vous?

Answer 5

Voici comment je modéliser: est discutable

CREATE TABLE Application_Users 
(
    user_id  INT NOT NULL, -- Maybe do without this if the user_name is unique 
    user_name VARCHAR(20) NOT NULL, 
    ... 
    CONSTRAINT PK_Application_Users PRIMARY KEY CLUSTERED (user_id) 
) 

CREATE TABLE Widgets  -- Items is a really bad table name generally 
(
    widget_id  INT NOT NULL, 
    widget_name VARCHAR(20) NOT NULL, 
    description VARCHAR(2000) NOT NULL, 
    ... 
    CONSTRAINT PK_Widgets PRIMARY KEY CLUSTERED (widget_id) 
) 

CREATE TABLE User_Widgets 
(
    user_id  INT NOT NULL, 
    widget_id INT NOT NULL, 
    ranking  SMALLINT NOT NULL, 
    CONSTRAINT PK_User_Widgets PRIMARY KEY CLUSTERED (user_id, ranking) 
) 

Le PK sur User_Widgets. Si elles ne peuvent avoir qu'une seule instance d'un widget particulier dans leur file d'attente à la fois, vous pouvez théoriquement mettre le PK sur (user_id, widget_id). S'ils peuvent avoir des liens pour le classement, vous pouvez placer le PK sur les trois colonnes. Cela dépend des besoins de l'entreprise.

Si vous incluez le classement dans le PK, gardez à l'esprit qu'il peut rendre les classements en mouvement pour les objets plus difficiles. Vous résoudriez généralement le problème en supprimant et en insérant des modifications plutôt que de mettre à jour des lignes. Par exemple, pour échanger les rangs 4 et 5, vous devez supprimer les deux rangées, puis les ajouter de nouveau aux rangs corrigés. Personnellement, je ne pense pas que ce soit une mauvaise chose, mais vous devez garder cela à l'esprit.

Answer 6

Cela devrait le faire; l'ordre appartient à la relation entre user et item. Si un élément peut appartenir à un seul utilisateur, placez une contrainte supplémentaire sur le ItemID in UserItem.