Quelle est la meilleure façon de stocker des formes dans une base de données

Question

Je suis en train d'implémenter une application qui traite des formes Java. chaque utilisateur se connecte et récupère un inventaire à partir d'une base de données MySql. les formes ont différents constructeurs et comportements.

Alors, quelle est la meilleure façon de stocker les formes? Voici quelques unes de mes idées:

• Sérialisez la forme et stockez-la sous forme de goutte. mais j'aurais un problème de versioning si je dois changer la classe de forme, en plus de la grande taille de la DB et la performance de requête
• Faites une table de forme avec les champs communs comme la largeur et la taille et une table pour chaque forme qui fait référence à la table Shape. Cela pourrait entraîner beaucoup de tables ...
• Faire une table de forme avec tous les champs possibles et vient de mettre nulle pour une forme qui n'a pas besoin du terrain ...

Que pensez-vous?

Answer 1

J'ai opté pour la deuxième solution, car il est facile à gérer et à étendre. L'option de sérialisation n'est pas pratique car si la structure du modèle sérialisé change (exemple: ajout d'un attribut), je dois gérer les versions du modèle. La troisième option n'est tout simplement pas la bonne approche pour créer des bases de données.

Answer 2

Quelques idées simples:

• Vous pouvez stocker une liste de sommets qui définissent le polygone.
• Vous pouvez stocker une liste de vecteurs qui définissent les arêtes du polygone.

Comment ils pourraient être stockés dans une base de données:

• table principale de forme, avec clé primaire une identité appelée « ShapeID »
• table vecteur, avec une clé primaire identifiant le VectorID, étranger la clé du ShapeID approprié, l'origine (coords x, y, z), la direction (x, y, z) et la longueur.

Des métadonnées supplémentaires peuvent être affectées à une forme avec d'autres tables qui font également référence à l'ID de forme par clé étrangère.

Answer 3

Il n'y a pas vraiment de "meilleure" façon de stocker une hiérarchie d'héritage dans une base de données. Il existe 3 modèles enseignés dans la plupart des cours de base de données: Table unique avec des valeurs nulles, Table par sous-classe et Table par classe concrète. Vous pouvez trouver une bonne explication dans this blog post. Vous pouvez choisir l'un de ceux que vous préférez si vous voulez simplement mapper les attributs de vos formes dans la base de données.

Si vous voulez quelque chose de plus avancé, MySql fournit un Geometry type spécialement conçu pour stocker des formes géométriques.

Answer 4

Je voterais:

• Faire une table de forme avec tous les champs possibles:

  • comme la largeur et la hauteur
  base de
  • et la hauteur
  • rayon ...
  • type de forme (par exemple 0 = cercle, 1 = carré, 3 = triangle, ...)

• Une table, toutes les formes possibles, une instance de forme/rangée

à mon humble avis ...

Q: Combien de formes différentes que vous pensez que vous pourriez avoir? Combien de colonnes pensez-vous que chaque forme pourrait prendre? Un «polygone» (composé d'un nombre arbitraire de points) pourrait mériter deux tables distinctes. Mais la plupart des formes (cercle, ellipse, carré, rectangle, etc.) ne devraient pas nécessiter plus de 4 ou 5 colonnes/instance, et devraient facilement tenir dans une table.

Answer 5

Techniquement pas une réponse, mais peut-être le problème ici est SQL? Je pense qu'un système de stockage de documents comme CouchDB pourrait être une solution beaucoup plus efficace pour ce scénario.

Je pense quelque chose comme ceci:

{ 
    "_id": "whatever", 
    "_rev": "whatever", 
    "boundingBox": [ 
     [0 0], 
     [2 2] 
    ], 
    "size": [2 2], 
    "circle": { 
     "center": [1 1], 
     "radius": 1 
    } 

}

La strophe "circle" changerait le nom et les détails en fonction de la forme. Rectangles aurait les coins (similaire à "boundingBox"), ellipsoïdes aurait ... Tout ce qui définit les ellipsoïdes: p