Structuration d'une base de données avec plusieurs clés étrangères pour haute performance

Question

J'essaye de construire une base de données locale pour android. Je suis un peu perdu.

L'application est une application de gestion des documents .. Je dois sauver ce qui suit ...

Document 
-------- 
Id 
import date 
List<DocTags> 
extension 
etc 

alors j'ai un certain nombre de docTags qui ont des informations différentes

Location 
------- 
id 
name 
lat 
long 

Company 
------ 
Id 
name 
Street 
town 

environ 10 autres types de doc.

Je me rends compte que j'ai besoin d'une table pour stocker tous les id docTag qui sont affectés à un document, mais ceux-ci se rapportent à beaucoup de tables différentes. Mon problème est que j'ai besoin de récupérer une liste de documents en cherchant l'ID doctag ou plusieurs ID de doctag. Nous devons supposer que nous avons 10 000 documents de plus, ce qui équivaut à 40 000 étiquettes de documents. La performance est donc un problème majeur. Quelle est la meilleure façon de structurer la base de données?

Je devrai également rechercher les noms de doctag.

Merci

Answer 1

J'ai plusieurs à plusieurs REJOIGNEZ tableau relatif à la balise du document.

Je voudrais pas avoir ces étiquettes dans plusieurs tables. Cela brise la première forme normale. Si d'autres tables doivent se référer aux lignes Tag, donnez-leur également des tables JOIN. Vos commentaires ci-dessous suggèrent qu'un rappel de normalisation est nécessaire ou qu'un modèle relationnel pourrait ne pas être le meilleur choix pour votre problème. Peut-être qu'une solution basée sur des documents NoSQL irait mieux.

Answer 2

Je suis jamais utilisé SQLite une ou deux fois, mais d'après mon expérience avec d'autres systèmes de base de données , je recommande fortement à commencer par un schéma relationnel solide, et l'évaluation du rendement, avant de tenter quoi que ce soit d'autre.

Dans votre cas, je pense que le schéma ressemblerait à ceci.

(Bien sûr, avec deux tables supplémentaires pour chaque doctag).

Vous aurez beaucoup de tables, et probablement une requête assez longue pour obtenir toutes les informations, mais ce n'est pas nécessairement une mauvaise chose. Le schéma relationnel permettra à l'optimiseur de la requête de faire son travail et rendra les requêtes futures plus faciles à écrire.

Une requête pour obtenir le document et toutes les informations sur son emplacement et de la société (ou retourner null si le document n'a pas cette balise) ressemblerait à ceci:

SELECT * FROM Document 
    LEFT JOIN DocumentLocation ON Document.ID=DocumentLocation.DocumentID 
     INNER JOIN Location ON DocumentLocation.LocationID=Location.LocationID 
    LEFT JOIN DocumentCompany ON Document.ID=DocumentCompany.DocumentID 
     INNER JOIN Company ON DocumentCompany.CompanyID=Company.CompanyID 

Si la performance de cette s'avère trop lent, vous pouvez alors étudier des stratégies pour améliorer les performances (par exemple, la mise en cache, les index supplémentaires) en fonction du modèle d'utilisation attendu de votre application.