Создание двух разных типов пользователей (Scala, Lift)

Question

Я создаю веб-сайт, которому понадобятся два типа пользователей:студенты и поставщики медицинских услуг.В традиционной настройке Java я бы создал пользовательский класс (или интерфейс), а затем создал два класса, унаследованных от пользователя.Является ли это лучшим курсом и в scala, использующим модификаторы "extends" и "with"?Если это действительно лучший способ (а я подозреваю, что это так), то каков наилучший способ отобразить это в БД?Было бы лучше сохранить столбец "тип", а затем установить для него одно или другое значение?

Второй вопрос заключается в том, как работать с представлением.Отображение будет сильно отличаться в зависимости от типа пользователя, и поэтому я полагаю, что будет задействована какая-то серьезная логика маршрутизации или, по крайней мере, логика, встроенная в фрагменты в представлении.

Я предполагаю, что главный вопрос заключается в следующем:Есть ли "предпочтительный" способ сделать это (например, рецепт в rails или что-то подобное), или я как бы сам по себе?

Спасибо

Answer 1

Если это действительно лучший способ (а я подозреваю, что это так), то каков наилучший способ отобразить это в БД?Было бы лучше сохранить столбец "тип", а затем установить для него одно или другое значение?

Я не думаю, что существует четкий "лучший способ" спроектировать структуру базы данных с учетом сценария.Ответ из учебника таков нормализация базы данных и СУХОЙ.

Подход из трех таблиц

Одним из способов, например, могло бы быть создание пользовательской таблицы, содержащей оба типа пользователей, хранящей только общие атрибуты, и создание таблицы Student и таблицы Provider с внешним ключом к пользовательской таблице и специализированными атрибутами, если таковые имеются.Вероятно, это не то, что рекомендовал бы специалист по традиционным реляционным базам данных, но это ближе к модели наследования OO.

Подход с одной таблицей

Другой подход, подобный тому, который вы сказали, состоял бы в том, чтобы просто создать поле "UserType" и сохранить оба типа пользователей в таблице User.Это просто, но тогда вы упускаете возможность воспользоваться преимуществами ссылочной целостности реляционной базы данных.Например, если вы должны были создать дочернюю таблицу, специфичную только для Student, такую как Домашнее задание, вы не можете просто создать внешний ключ для StudentID, если и students, и providers жили в User table.

Подход к двум таблицам

Если вы используете Object-Relational Mapping framework, вероятно, самый простой способ - отобразить именно то, что вы хотите в объектном мире, прямо в базу данных, которая будет иметь таблицу Student и таблицу Provider, и выразить общность двух как признак на стороне Scala.

Я нашел Лифт шпаргалка:

Определение моделей

сопоставленные модели lift O-R определяются на основе класса с полями.

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
  }
}

Обсуждение того, чтобы иметь общие базовые характеристики для Моделей.

В теме Дэвид Поллак пишет:

Вы ищете немного магии 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]