Modellierung von Klassen auf der Grundlage von Tabellenentwürfen

Question

Würden Sie den Unterricht normalerweise so gestalten? Eine Klasse = 1 Tisch. Wie sieht es mit Tabellen aus, die einen Fremdschlüssel zu einer anderen Tabelle enthalten?

Angenommen, ich habe Folgendes:

PersonTable
---------------
person_id
name

PersonMapTable
---------------
map_id
type_id (fk)
person_id

PersonTypeTable
-------------------
type_id
description
parent_type_id

AddressTable
-------------------
address_id
address1
address2
city
state
zip

AddressMapTable
-----------
address_map_id
address_id
person_id

Wäre es eine gute Praxis, für jede Tabelle eine Klasse zu erstellen? Wenn ja, was sind die besten Praktiken für das Laden/Speichern solcher Klassen zurück in die Datenbank ohne einen Orm? Ein einfaches Codebeispiel wäre sehr hilfreich

Answer 1

Wenn Sie planen, Object-Relational Mapping (ORM) zu verwenden, kann sich dies auf Ihren Tabellenentwurf auswirken. Winterschlaf mag zum Beispiel keine gemischten Vererbungsstrategien innerhalb desselben Baums.

Da Sie ausdrücklich darauf hingewiesen haben, dass Sie kein ORM verwenden werden, können Sie sich an die traditionellen Prinzipien des Datenbankdesigns halten. Das bedeutet in der Regel, dass Sie mit einer Tabelle pro Klasse beginnen, die in die dritte Normalform normalisiert wird ( Lesen Sie hier über Datenbanknormalisierung ), dann Denormalisierung zur Erfüllung der Leistungsvorgaben ( Lesen Sie hier über Denormalisierung ).

In Bezug auf Ihre Frage, wie Sie die Objekte ohne ORM laden und speichern können, ist eine gängige Strategie die Verwendung von Data Access Objects ( DAO s). Hier ist ein einfaches Beispiel:

public interface ICustomerDao
{
  public void insert(Customer customer) throws CustomerDaoException;
  public void update(long id, Customer customer) throws CustomerDaoException;
  public void delete(long id) throws CustomerDaoException;
  public Customer[] findAll() throws CustomerDaoException;
  public Customer findByPrimaryKey(long id) throws CustomerDaoException;
  public Customer[] findByCompany(int companyId) throws CustomerDaoException;
}

Sie haben nicht angegeben, welche Sprache Sie verwenden, aber unabhängig davon finden Sie vielleicht dieses Beispiel mit Java-Generik für DAO nützlich.

Answer 2

Würde eine gute Praxis darin bestehen für jede Tabelle eine eigene Klasse zu erstellen? Wenn ja, was sind die besten Praktiken für Laden/Speichern solcher Klassen zurück in die in die Datenbank ohne ein Orm?

Sie verwenden ORM. Sie bilden Objekte auf relationale Tabellen ab. Ob Sie dazu eine vorgefertigte Bibliothek verwenden oder nicht, ist Ihre Entscheidung. Wenn Sie dies nicht tun, implementieren Sie im Grunde genommen selbst eine ORM, wenn auch wahrscheinlich ohne den ganzen Schnickschnack der bestehenden ORMs.

Die beiden gebräuchlichsten Methoden hierfür sind das ActiveRecord-Muster und das Data-Mapper-Muster. Beide haben ihre Vor- und Nachteile.

Mit dem ActiveRecord-Muster definieren Sie Klassen, deren Attribute die Tabellenspalten für Sie definieren. Jede Instanz dieser Klasse entspricht einer Zeile in der Datenbank, und indem Sie eine neue Instanz erstellen (und speichern), legen Sie eine neue Zeile in der Datenbank an. Weitere Informationen dazu finden Sie hier: http://en.wikipedia.org/wiki/Active_record_pattern

Beim Data-Mapper-Muster definieren Sie Tabellenobjekte für jede Tabelle und schreiben Mapper-Funktionen, die Spalten der Tabelle bestehenden Klassen zuweisen. SQLAlchemy verwendet dieses Muster standardmäßig (obwohl es ActiveRecord-Typ-Erweiterungsmodule gibt, die die Funktionalität von SQLAlchemy an eine andere Schnittstelle anpassen. Eine kurze Einführung in dieses Muster findet sich in der Dokumentation von SQLAlchemy hier: http://www.sqlalchemy.org/docs/05/ormtutorial.html (lesen Sie von Anfang an bis zum Abschnitt "Tabelle, Klasse und Mapper auf einmal deklarativ erstellen", der ActiveRecord mit SQLAlchemy erklärt).

Das ActiveRecord-Muster ist einfacher einzurichten und zu verwenden und gibt Ihnen Klassen, die eindeutig für Ihre Datenbank repräsentativ sind, was Vorteile in Bezug auf die Lesbarkeit hat. Als Nebeneffekt dient die deklarative Natur der ActiveRecord-Klassen als klare und einfache Dokumentation für Ihr Datenbankschema.

Das Data-Mapper-Muster bietet Ihnen weitaus mehr Flexibilität bei der Zuordnung Ihrer Daten zu Ihren Klassen, so dass Sie nicht an eine mehr oder weniger eins-zu-eins-Beziehung zwischen Tabellen und Klassen gebunden sind. Außerdem trennt es Ihre Persistenzschicht von Ihrem Geschäftscode, was bedeutet, dass Sie später andere Persistenzmechanismen austauschen können, falls dies erforderlich ist. Das bedeutet auch, dass Sie Ihre Klassen leichter testen können, ohne dass Sie eine Datenbank für sie einrichten müssen.

Für eine ausführlichere Diskussion über die Mapper-Konfiguration von SQLAlchemy lesen Sie bitte http://www.sqlalchemy.org/docs/05/mappers.html . Auch wenn Sie nicht vorhaben, eine Bibliothek wie SQLAlchemy zu verwenden, sollte die Dokumentation Ihnen helfen, einige der Optionen zu erkennen, die Sie bei der Zuordnung Ihrer Klassen zu Datenbanktabellen in Betracht ziehen sollten.

Answer 3

Diese Sichtweise von der Datenbank zur Klasse wird Sie wahrscheinlich schnell zu einer Menge Code führen. Ein großer Teil dieses Codes wird jedoch wahrscheinlich nicht von Nutzen sein oder eine starke Mutation erfordern. Mit anderen Worten: Sie werden wahrscheinlich spezielle Klassen erstellen, die nicht zu Ihren Anzeigen und Arbeitsabläufen passen.

Überlegen Sie sich zunächst Ihre Anwendungen, die Bedürfnisse Ihrer Benutzer, den allgemeinen Arbeitsablauf usw. Überlegen Sie sich etwas, das praktikabel aussieht (d. h. stellen Sie Ihre Displays nach).

Konzentrieren Sie sich auf die Klassen, die Sie für die Anzeigen benötigen, und modellieren Sie Ihre Ablage (db design) nach diesen Anforderungen. Die Chancen stehen gut, dass Sie nur wenige reine Tabellenklassen haben werden, da die meisten Ihrer Klassen die Lösung für Ihre Anzeigen bieten.

Viel Glück!