La création de deux types d'utilisateurs différents (Scala, Lift)

Question

Je suis en train de créer un site Web qui aura besoin de deux types d'utilisateurs: les étudiants et les fournisseurs. Dans un cadre java traditionnel je voudrais créer une classe d'utilisateurs (ou interface), puis créer deux classes qui ont hérité de l'utilisateur. Est-ce le meilleur en scala aussi, en utilisant le « étend » et « avec » modificateurs? Si tel est la meilleure façon (que je soupçonne qu'il est), quelle est la meilleure façon de mapper ce dans le DB? Serait-il préférable de garder une colonne « type », puis l'ont mis à l'un ou l'autre?

La deuxième question est de savoir comment travailler avec la vue. L'affichage sera très différente selon le type d'utilisateur est l'un et donc je comprendre qu'il y aura une certaine logique de routage sérieux impliqués ou au moins une logique intégrée dans des extraits dans la vue.

Je suppose que la question fondamentale est: Est-il possible « préféré » aller à faire cela (comme une recette dans des rails ou quelque), ou suis-je sorte de sur ma propre

?

Merci

Answer 1

  

Si tel est la meilleure façon (que je soupçonne qu'il est), quelle est la meilleure façon de la carte ce dans le DB? Serait-il préférable de garder une colonne « type » et l'ont mis à l'un ou l'autre?

Je ne pense pas qu'il y ait clairement « la meilleure façon » à la structure de base de données conception dans un scénario donné. La réponse du livre de texte est la normalisation de base de données et SEC .

Trois tables approche

Une façon, par exemple, pourrait être de créer la table utilisateur contenant les deux types d'utilisateurs, en ne stockant que les attributs communs et créer la table des étudiants et tableau des fournisseurs avec clé étrangère à la table des utilisateurs et des attributs spécialisés le cas échéant. Ceci est probablement pas ce qu'est une personne de base de données relationnelle traditionnelle recommanderait, mais des cartes plus proches du modèle d'héritage OO.

Une approche de la table

Une autre approche comme vous avez dit serait de créer simplement un champ « UserType » et stocker les deux types d'utilisateurs dans la table des utilisateurs. Il est simple, mais vous manquez alors l'occasion de profiter de l'intégrité référentielle de la base de données relationnelle. Par exemple, si vous deviez créer table enfant uniquement spécifique aux étudiants, comme les devoirs, vous ne pouvez pas simplement la clé étrangère StudentID si les étudiants et les fournisseurs vivaient dans le tableau de l'utilisateur.

Deux tables approche

Si vous utilisez framework de mapping objet-relationnel, probablement la meilleure façon d'aller est à la carte exactement ce que vous voulez dans le détroit du monde des objets dans la base de données, ce qui serait d'avoir la table des étudiants et tableau des fournisseurs, et d'exprimer les points communs des deux comme trait à côté Scala.

J'ai trouvé Ascenseur antisèche :

  

Modèles Définition

     

ascenseur O-R modèles mis en correspondance sont définis sur la base d'une classe avec des champs.

class WikiEntry extends KeyedMapper[Long, WikiEntry] {
  def getSingleton = WikiEntry // what's the "meta" object
  def primaryKeyField = id

  // the primary key
  object id extends MappedLongIndex(this)

  // the name of the entry
  object name extends MappedString(this, 32) {
    override def dbIndexed_? = true // indexed in the DB
  }

  object owner extends MappedLongForeignKey(this, User)

  // the text of the entry
  object entry extends MappedTextarea(this, 8192) {
    override def textareaRows  = 10
    override def textareaCols = 50
  }
}

  

Discussion sur traits de base communs pour les modèles .

Dans le fil David Pollak écrit:

  

Vous cherchez quelque chose de magique Scala:

trait Posting[MyType <: Mapper[MyType]] { // Defines some common fields for posted user content 
  self: MyType => 
  def primaryKeyField = id 
  object id extends MappedLongIndex(this) 
  object creator extends MappedLongForeignKey(this, User) 
  object createdAt extends MappedLong(this) { 
    override def defaultValue = System.currentTimeMillis 
  } 
} 

class FooPosting extends KeyedMapper[FooPosting] with Posting[MyType]