Dans un cas simple comme ici oui un attribut de type enum peut suffire.
Mais j'ai eu des cas bien plus complexes ou c'était bien plus alambiqué et un enum était loin de convenir.
Par exemple si une VoitureDeCourse et une VoitureDeTourisme ont chacune besoin d'avoir des attributs propres et distincts. Ou si fonctionnellement tu as une méthode ou un attribut transient qui doit avoir deux implémentations séparées, ...
Bref on est en POO et l'héritage est quelquechose d'incontournable et certains modèles de données sont tels que c'est un peu impensable de faire sans.
Dire qu'on peut remplacer un héritage de classe par un attribut type enum, c'est aller contre le principe POO. Personne, la POO je trouve trop élégant. Ensuite que les percs soient pas au rdv...... C'est une autre histoire.
J'aimerais bien qu'on ait l'héritage multiple aussi. Quitte évidemment à penser une mise en place qui règle bien les problèmes de conflit.
Dire qu'on peut remplacer un héritage de classe par un attribut type enum, c'est aller contre le principe POO. Personne, la POO je trouve trop élégant.
Oui j'entends bien. Ceci dit un peu d'entorse à la règle ce n'est pas non plus catastrophique (quand c'est bien dosé).
Ensuite que les percs soient pas au rdv...... C'est une autre histoire.
Pas forcément une autre histoire : faire du model dans CoreData c'est prendre en compte aussi les perfs induites et donc faire des compromis : dupliquer des données n'est pas forcément une mauvaise chose, la dénormalisation également. (Attention, je n'ai jamais utilisé core data autre part que sur iOS).
dupliquer des données n'est pas forcément une mauvaise chose, la dénormalisation également.
heu au contraire si je dirais que c'est plutôt dangereux en général (et va à l'encontre à la fois des principes de bases d'un bon MDD, et augmente les risques de corruption). La consistance est du coup bien plus complexe à maintenir (voire peut vite devenir un vrai casse-tête, crois moi je l'ai déjà expérimenté lors d'une reprise de projet). Et enfin toi qui parle de performance c'est du coup étonnant d'entendre ça car pour garder la consistance dans ce cas il faut dupliquer les INSERT/UPDATE. Et quand tu commences aussi à avoir des dépendances chaà®nées le maintient de la consistance sur la duplication de données est un vrai enfer.
J'aimerais bien qu'on ait l'héritage multiple aussi. Quitte évidemment à penser une mise en place qui règle bien les problèmes de conflit.
Pitié non pas ça !!! En dehors de toutes les mauvaises choses que cela apporte (entre autres le diamond shape paradox mais pas que) conceptuellement c'est aussi plutôt tordu. Plutôt utiliser la composition pour ça !
heu au contraire si je dirais que c'est plutôt dangereux en général (et va à l'encontre à la fois des principes de bases d'un bon MDD, et augmente les risques de corruption). La consistance est du coup bien plus complexe à maintenir (voire peut vite devenir un vrai casse-tête, crois moi je l'ai déjà expérimenté lors d'une reprise de projet). Et enfin toi qui parle de performance c'est du coup étonnant d'entendre ça car pour garder la consistance dans ce cas il faut dupliquer les INSERT/UPDATE. Et quand tu commences aussi à avoir des dépendances chaà®nées le maintient de la consistance sur la duplication de données est un vrai enfer.
J'ai fait des référentiels en finances, en gestion articles etc... tout ça géré par des bases du genre Oracle, DB2 ou Microsoft et je me suis toujours appliqué à respecter les principes de bases de la conception d'un modèle de données.
Là dessus pas de soucis.
Avec CoreData c'est sensiblement différent (mon avis hein).
Si j'ai une entité voiture avec des relations un peu partout et pas mal d'attributs et qu'en face j'ai une UITableViewController associé à un NSFetchedResultsController qui est censé m'afficher juste le nom de la voiture et sa date de sortie, alors je vais créer une entité ListeVoiture qui contiendra les attributs (certes dupliqués) displayNom et displayDateSortie. Je vais fetcher cette entité et le résultat sera instantané. Si j'avais fait mon fetch avec Voiture, le fetch aurait ramené tous les attributs de l'entité (alors que tu en veux que deux) et si en plus tu vas chercher des attributs d'une relation c'est encore pire (faults en cascade).
Evidement ListeVoiture a une relation avec Voiture.
Avec un type de relation ListeVoiture<--->Voiture, les mises à jour ponctuelles sont instantanées et les grosses mise à jour sont de toute façon réalisées en arrière plan.
En résumé, je pèse le pour et le contre, entre normalisation / performance / maintenabilité.
@Kubernan : Oulà clairement ce n'est pas la meilleure façon de faire (et lève les problèmes de duplication évoqués plus haut).
1) Tu peux tout à fait avec CoreData demander de ne récupérer que certains attributs de tes entités et pas tous. Comme tu ferais un "SELECT name, date FROM voitures" en SQL au lieu d'un "SELECT * FROM voitures". Donc je ne comprends pas trop ton "si j'avais fait un fetch avec Voiture, le fetch aurait ramené tous les attributs" ?
2) Le principe de faulting sur les relationships est aussi justement fait pour ça.
3) Apple recommande d'ailleurs de mettre à profit le faulting pour profiter du fetch partiel automatiquement, sans même avoir besoin de préciser à chaque fois que tu ne veux que certains attributs.
Par exemple, plutôt que d'avoir une entité Voiture qui contient tous les attributs, et une entité ListeVoiture qui contient uniquement les attributs de noms et date, dupliqués et donc à maintenir en permanence, il est recommandé d'avoir une entité Voiture qui contient juste les données de base (nom et date) + une relationShip "details" vers une autre entité VoitureDetails, contenant elle tous les autres attributs. Ainsi, quand tu demandes de récupérer toutes les voitures ([Voiture findAll]) il ne va récupérer que les attributs directs de Voiture, donc nom et date. Et c'est seulement si tu cherches à lever la fault, en demandant voiture.details pour résoudre ta relationShip, que les autres champs seront fetchés. Et tu n'as aucune duplication de données.
Dans la doc Apple prend comme exemple pour cela le cas où tu as des BLOB de données assez larges (comme un NSData), justement pour éviter de les charger systématiquement tant que ce n'est pas nécessaire, et ne les charger que quand tu cherches à résoudre la fault.
Avec ce genre de solution, et de mise à profit du faulting intrinsèque à CoreData, tu gardes tous les avantages à la fois de la performance, de la maintenabilité, tout en évitant la duplication et tout ce que cela engendre. Les noms des voitures ne sont jamais dupliqués, comme il se doit dans tout modèle de données (que ce soit un modèle objet ou un modèle de Base de Données d'ailleurs, c'est un peu à la base pour ça que les relationships sont faites aussi)
@Kubernan : Oulà clairement ce n'est pas la meilleure façon de faire (et lève les problèmes de duplication évoqués plus haut).
Carrément pas d'accord.
1) Tu peux tout à fait avec CoreData demander de ne récupérer que certains attributs de tes entités et pas tous. Comme tu ferais un "SELECT name, date FROM voitures" en SQL au lieu d'un "SELECT * FROM voitures". Donc je ne comprends pas trop ton "si j'avais fait un fetch avec Voiture, le fetch aurait ramené tous les attributs" ?
Ce que tu dis ne fonctionne que si tu ramènes un dictionnaire.
Je parlais d'un truc qu'on utilise souvent avec les UITableView : le NSFetchedResultsController. Là tu peux pas demander à ramener tel ou tel attribut. Il ramène tout les attributs (je parle des attributs, pas des relations).
Oui et si tu écoutes les retours de discussion à la WWDC avec les gars qui ont fait ces sessions ça confirme la préconisation d'utilisation du pattern de composition (relationship one-to-one). Ce qui en passant n'est pas nouveau, et est déjà une pratique qu'on préconise également dans les SGBD.
J'ai pas eu de retours de discussions et je ne remets nullement en question le one-to-one, mais en tout cas ça cause bien de dénormalisation et de duplication.
Réponses
Mais j'ai eu des cas bien plus complexes ou c'était bien plus alambiqué et un enum était loin de convenir.
Par exemple si une VoitureDeCourse et une VoitureDeTourisme ont chacune besoin d'avoir des attributs propres et distincts. Ou si fonctionnellement tu as une méthode ou un attribut transient qui doit avoir deux implémentations séparées, ...
Bref on est en POO et l'héritage est quelquechose d'incontournable et certains modèles de données sont tels que c'est un peu impensable de faire sans.
J'aimerais bien qu'on ait l'héritage multiple aussi. Quitte évidemment à penser une mise en place qui règle bien les problèmes de conflit.
Là de suite non. Faudrait se retaper les vidéos wwdc sur Core Data.
Oui j'entends bien. Ceci dit un peu d'entorse à la règle ce n'est pas non plus catastrophique (quand c'est bien dosé).
Pas forcément une autre histoire : faire du model dans CoreData c'est prendre en compte aussi les perfs induites et donc faire des compromis : dupliquer des données n'est pas forcément une mauvaise chose, la dénormalisation également. (Attention, je n'ai jamais utilisé core data autre part que sur iOS).
J'ai fait des référentiels en finances, en gestion articles etc... tout ça géré par des bases du genre Oracle, DB2 ou Microsoft et je me suis toujours appliqué à respecter les principes de bases de la conception d'un modèle de données.
Là dessus pas de soucis.
Avec CoreData c'est sensiblement différent (mon avis hein).
Si j'ai une entité voiture avec des relations un peu partout et pas mal d'attributs et qu'en face j'ai une UITableViewController associé à un NSFetchedResultsController qui est censé m'afficher juste le nom de la voiture et sa date de sortie, alors je vais créer une entité ListeVoiture qui contiendra les attributs (certes dupliqués) displayNom et displayDateSortie. Je vais fetcher cette entité et le résultat sera instantané. Si j'avais fait mon fetch avec Voiture, le fetch aurait ramené tous les attributs de l'entité (alors que tu en veux que deux) et si en plus tu vas chercher des attributs d'une relation c'est encore pire (faults en cascade).
Evidement ListeVoiture a une relation avec Voiture.
Avec un type de relation ListeVoiture<--->Voiture, les mises à jour ponctuelles sont instantanées et les grosses mise à jour sont de toute façon réalisées en arrière plan.
En résumé, je pèse le pour et le contre, entre normalisation / performance / maintenabilité.
1) Tu peux tout à fait avec CoreData demander de ne récupérer que certains attributs de tes entités et pas tous. Comme tu ferais un "SELECT name, date FROM voitures" en SQL au lieu d'un "SELECT * FROM voitures". Donc je ne comprends pas trop ton "si j'avais fait un fetch avec Voiture, le fetch aurait ramené tous les attributs" ?
2) Le principe de faulting sur les relationships est aussi justement fait pour ça.
3) Apple recommande d'ailleurs de mettre à profit le faulting pour profiter du fetch partiel automatiquement, sans même avoir besoin de préciser à chaque fois que tu ne veux que certains attributs.
Par exemple, plutôt que d'avoir une entité Voiture qui contient tous les attributs, et une entité ListeVoiture qui contient uniquement les attributs de noms et date, dupliqués et donc à maintenir en permanence, il est recommandé d'avoir une entité Voiture qui contient juste les données de base (nom et date) + une relationShip "details" vers une autre entité VoitureDetails, contenant elle tous les autres attributs.
Ainsi, quand tu demandes de récupérer toutes les voitures ([Voiture findAll]) il ne va récupérer que les attributs directs de Voiture, donc nom et date. Et c'est seulement si tu cherches à lever la fault, en demandant voiture.details pour résoudre ta relationShip, que les autres champs seront fetchés. Et tu n'as aucune duplication de données.
Dans la doc Apple prend comme exemple pour cela le cas où tu as des BLOB de données assez larges (comme un NSData), justement pour éviter de les charger systématiquement tant que ce n'est pas nécessaire, et ne les charger que quand tu cherches à résoudre la fault.
Avec ce genre de solution, et de mise à profit du faulting intrinsèque à CoreData, tu gardes tous les avantages à la fois de la performance, de la maintenabilité, tout en évitant la duplication et tout ce que cela engendre. Les noms des voitures ne sont jamais dupliqués, comme il se doit dans tout modèle de données (que ce soit un modèle objet ou un modèle de Base de Données d'ailleurs, c'est un peu à la base pour ça que les relationships sont faites aussi)
Carrément pas d'accord.
Ce que tu dis ne fonctionne que si tu ramènes un dictionnaire.
Je parlais d'un truc qu'on utilise souvent avec les UITableView : le NSFetchedResultsController. Là tu peux pas demander à ramener tel ou tel attribut. Il ramène tout les attributs (je parle des attributs, pas des relations).
Vidéo wwdc 2012 session 214 - Core Data Best Practices, à partir de 32 minutes.
Vidéo wwdc 2013 session 211 - Core Data Performances, à partir de 7:47
J'ai pas eu de retours de discussions et je ne remets nullement en question le one-to-one, mais en tout cas ça cause bien de dénormalisation et de duplication.
Merci Kubernan