L'ossessione primitiva si applica alle colonne di tabelle nel database?

Question

L'ossessione primitiva si applica alle colonne di tabelle nel database?

#1 da (4 voti)

0

Ad esempio, in un oggetto Studente, per evitare l'ossessione primitiva, dovrei cambiare

public class Student{
    public String name;
    public int age;
}

in

public class Student{
    public Name name;
    public Age age;
}

in modo che il nome e l'età abbiano il loro oggetto. Tuttavia, nel database, di solito memorizzo Nome ed Età in testo normale o int:

CREATE TABLE Students
  ID int NOT NULL,
  Name varchar(255),
  Age int,
  PRIMARY KEY (ID)

La mia domanda è, idealmente, dovrei creare una tabella per un campo:

CREATE TABLE Students
  ID int NOT NULL,
  PRIMARY KEY (ID)

CREATE TABLE Names
  value varchar(255),
  CONSTRAINT student_id PRIMARY KEY (ID)

CREATE TABLE Ages
  value INT,
  CONSTRAINT student_id PRIMARY KEY (ID)

Quindi ogni campo ha le sue tabelle?

database data-types

posta mmmaaa 30.07.2018 - 06:33

fonte

1 risposta

Leggi altre domande sui tag database data-types

Dove è necessario includere convalide della logica non commerciale in Livello di servizio Il lato "uno" della relazione si applica anche allo stesso record?

score 4 · Accepted Answer

Non dovresti creare tabelle inutili.

In primo luogo, considera perché "l'ossessione primitiva" è considerata un antipattern in primo luogo. Incapsulando "Age" nella propria classe si possono applicare vincoli e validazioni specifiche per questo tipo - es. assicurandoti che non sia negativo, aggiungi la logica specifica del dominio per calcolare le età e puoi limitare le operazioni valide per età.

Ma ottieni nessuno di questi benefici dividendo il campo dell'età in una tabella separata. È ancora possibile eseguire esattamente le stesse operazioni sull'età di prima poiché il concetto di incapsulamento non si applica realmente alle tabelle del database. Quindi creare una tabella separata non ha alcun vantaggio e complicherà molto il tuo codice.

Quello che puoi fare (almeno negli stessi database) è creare un tipo di dati distinto per Age, ma averlo ancora nella stessa tabella. La maggior parte dei database ti consente di creare i tuoi tipi di dati. Se questo vale la pena è un'altra domanda. Se si dispone di una semplice applicazione CRUD in cui tutte le manipolazioni dei dati si verificano nel codice dell'applicazione, il vantaggio potrebbe non essere grande. Se disponi di un sacco di SQL o di un sistema aziendale in cui più applicazioni accedono allo stesso database, potrebbero esserci molti vantaggi nella creazione di tipi personalizzati.

(A proposito, dovresti probabilmente archiviare l'anno di nascita piuttosto che l'età!)