Le magasin de données utilisé par Google's App Boîte, contrairement à un moteur de base de données relationnelle, n'applique pas les schémas - au lieu de lignes et de colonnes, il stocke des entités avec diverses propriétés. Néanmoins, il faut toujours utiliser une conception de base de données traditionnelle?
Par exemple, disons que j'ai une application qui suit divers véhicules locatifs. Dans une base de données traditionnelle, je peux avoir une table , qui suit la longueur et le nombre de sièges pour chaque bus dans la flotte et Dans le magasin de données de Google, je serais tenté de simplement stocker des bus et des camions comme des entités , car ils partagent les propriétés communes et ajouter toutes les propriétés spécifiques au type de véhicule.
Quels sont les avantages / inconvénients à l'utilisation d'un modèle de base de données traditionnel, où chaque entité de magasin de données représente une table de base de données?
est-il plus efficace de briser de grandes entités dans des entités plus petites?
En outre, toutes les recommandations concernant les API à utiliser: JDO, JPA ou l'API de bas niveau de Datastore?
merci! camions , qui a une colonne pour le Capacité de charge et puissance de chevaux pour chaque camion. Chaque bus et camion disposent également d'un numéro de couleur et de plaque d'immatriculation. (Si je veux normaliser la base de données, je pourrais séparer ces attributs dans un véhicule table).
3 Réponses :
Vous ne devriez pas penser aux tables du tout. Pensez aux entités. La documentation stipule que:
Les entités de DataStore sont schématiques: Deux entités du même type ne sont pas obligées d'avoir les mêmes propriétés ou d'utiliser les mêmes types de valeur pour les mêmes propriétés. L'application est chargée de veiller à ce que les entités soient conformes à un schéma si nécessaire.
Les meilleures performances sont généralement réalisées par des données de normalisation. Donc, vous êtes probablement mieux à partir de deux types d'entité distincts,
bus etcamion et ignorant le fait qu'ils partagent certaines propriétés.
Si vous utilisez Python, regardez le Polymodel classer. Il offre un moyen pratique de dénormaliser vos données tout en conservant certaines séparations logiques entre différents types. Si vous aurez de nombreux types, vous pouvez obtenir le même résultat qu'un polymodel à l'aide d'un Expando .
En général, la taille d'une entité aura peu d'impact sur la performance. Le numéro d'entités a un impact de performance beaucoup plus important. En d'autres termes, privilégiez moins d'entités.
Comme Klausbyskov a souligné, ne pensez pas en termes de bases de données relationnelles. En fin de compte, la performance de votre application souffrira probablement parce que vous devrez faire de nombreuses requêtes et extratens supplémentaires. Pour comprendre certaines des différences clés, consultez « Maîtriser le magasin de données ' Articles.
Une seule clarification: la performance est en référence au temps nécessaire pour aller chercher ou stocker les entités.
C'était une question qui m'a perplexe depuis longtemps. Je pense que la façon dont vous voulez rechercher sur l'entité fait une différence significative pour décider d'un modèle de conception. Une chose qui me fait mal était que, dans l'App moteur, vous ne peut pas utiliser Filtres d'inégalité sur plusieurs propriétés de la même entité.
Par exemple: Vous ne pouvez pas interroger une «personne» pour l'âge> 20 et la hauteur <170. Parce que l'âge et la hauteur sont des propriétés différentes sur la même entité.
J'ai utilisé JDO pour mon application et cela fonctionne bien jusqu'à présent. J'ai décidé de l'utiliser depuis Ce livre que j'avais , a fourni de nombreux exemples du monde réel de requêtes JDO dans App Moteur.
J'ai dû dénormaliser et diviser ces propriétés pour faire les requêtes. Vous pouvez regarder la vidéo de Bret Salkin sur Google I / O pour mieux comprendre les méthodes de conception de DB. J'ai fait et une couverture entière de Mon expérience avec DataStore Modéling dans Google App Moteur ici .