1.5 java: Best Practice Konstanten für Spaltennamen von db Tabellen zu halten?

Question

Technologie: - Java 1.5 oder 1.6 - Hibernate 3.4

Um zu vermeiden, Aktualisierung von Spaltennamen an mehreren Stellen über den Wechsel der Spaltennamen oder Tabellennamen, ich mag für gleiche eine konstante Datei haben.

Ich habe folgende Fragen?

• Eine mögliche Lösung ist eine globale Datei, die speichert Konstanten für Spaltennamen aller Tabellen in der Datenbank zu erhalten. wie

  class DbConstants
  {
          public static final String EMPLOYEE__PERFORMANCE_DESC="performance_desc";        
  } 
  

Im obigen Fall Mitarbeitern ist der Name der Tabelle und performance_desc ist der Name des Spaltennamen. So Art von tablename__columnname Format folgt für eine Konstante zu vermeiden Kollision zwischen zwei Konstanten von zwei verschiedenen Tabellen zu benennen, wenn beide Namen Spalte haben.

Ein Problem bei diesem Ansatz, den ich sehe, ist, dass als Datenbank wächst nicht von Konstanten in dieser Datei werden zu Tausenden wachsen, die schwer zu verwalten. Anderes Problem ist, wenn Tabellenname geändert wird, muß ich für alle Tabellen-Präfix-Tabelle Namen ändern.

• Nehmen wir an, wenn ich Namen der Spalte in obigen Beispiel von performance_desc zu achievements_desc ändern. In diesem Fall ist es sehr wahrscheinlich, dass ich ändert konstant wie auch das heißt von EMPLOYEE__PERFORMANCE_DESC zu EMPLOYEE__ACHIEVEMENT_DESC. Da in diesem Fall ich beide Spaltennamen ändern musste und konstanten Namen ich sehe nicht viel Gebrauch von konstanten anstelle von Spaltennamen direkt in meinem Code, obwohl es ein Vorteil ist, dass der konstante Namen auf Änderung kann ich Brechung verwenden konstant zu reflektieren Namensänderung wohin verwiesen. Es scheint, entweder gibt es nicht viel Gebrauch von Konstanten oder ich es falsch verwende.

• Im Projektcode i haben scheinen die Menschen definieren eine Klasse für jede Liste Tabellenspalten Konstanten zu definieren, wie unten dargestellt.

  public class tbl_Employee
  {
          public static final PERFORMANCE_DESC=performance_desc;
  }    
  

Dies kann einige Probleme mit globaler Datei wie Tischnamensänderung lösen wird nur Klasse Namensänderung führen. Ein großes Problem dabei ist, dass ich Klasse verwende für alleinigen Zweck der Konstanten definieren, was nicht gut Codierung der Praxis.

• Lesen Sie einige, wo über Enum mit String-Wert, anstatt int nicht sicher, dass es in Java 1.5 oder 1.6 verfügbar ist und sein ratsam ist, in bestimmtem Szenario zu verwenden.

• Was ist Best Practice für db Konstanten gegebenen definieren?

• Ist es wirklich sinnvoll DB Konstanten zu verwenden?

• Wenn ich für jede Tabelle eine Klasse verwenden, wie oben erwähnt, ein Problem, das ich Gesicht Namenskonvention. Was Beziehung zwischen Namen der Tabelle und den entsprechenden Klasse Namen, die Konstanten für Spalten der Tabelle definieren.

sein sollte

• über Fälle Abdeckungen Fall für nur Spaltennamen nicht Tabellennamen. Ich kann gerne konstant eher Tabellennamen im Code verwenden, so was Ansatz sollte Konstanten für Tabellennamen zu definieren.

• Es wird oft argumentiert, dass Tabellennamen und Spaltennamen nicht viel ändern, sobald Produkt oder eine ähnliche Version freigegeben wird. Änderungen in Tabellennamen und Spaltennamen passieren meist während Entwicklungsphase oder Funktionserweiterung (neue Version). Ist es starke Argument mit Konstanten für Tabellennamen oder Spaltennamen zu vermeiden?

  Bitte legen nahe, wie kann ich meine Frage mehr darstellbare machen oder was ich bin fehlt, dass meine Fragen gestimmt nicht?

Answer 1

It sounds like you're asking all the right questions - you want to make the code more maintainable, but realize that this could get unwieldy and end up making the code worse rather than better. Think of something like "Color.RED, Color.BLACK".

I've found that a reasonable amount of constants like this makes the code more readable. I don't think db column names belong in something like this, because

• they're not going to be changed often, or at least they shouldn't be

• there's enough of them that you'll end with a large list of constants, at which point people stop using them because it's harder to find the constant than to just look up the damn name in the db.

I've seen db files like this with thousands of constants, including custom queries, parts of queries, etc. etc (even a gem like public static final String COMMA=","; to take care of the possibility that the spelling of commas will change in the future). At this point they devolve into "use once" strings, and nobody dares to change them.

One other caveat about string constants - finals get compiled into your class as strings. So if you recompile the constant class, but not the class that uses the definition, it's possible to end up with the new definition not propagating.

Answer 2

Have you considered using an Entity Mapping Framework (like Hibernate)?

It can store all of the database table information (as well as all other DB specific information) in a configuration file. It also offers a separation layer between "hard" DB design and your application (which would make it easier to absorb changes to either).

Answer 3

On my current project, we are making heavy use of annotations for a lot of the DB-related metadata because we can't use a framework like Hibernate. For actual column constants, yes, we use the tried and true public static final String. And yes, it's fairly fragile.

Answer 4

You could create an interface that defines the constants.

Here's a good example in Android. Look for the DataColumns interface.

Answer 5

When I have meta data about a database, I would store this in the database also. This is how I have seen other system run, if not initially then eventually. To ensure this data is maintained you could check against the schema of the data base.