Aus diesem Grund habe ich mir bereits vor langer Zeit angewöhnt, die Index-Spalte einer Tabelle stets mit dem Tabellen-Namen zu verbinden, z.B. Idx_Adressen, Idx_Kategorie usw. Nach Möglichkeit sollte man Tabellen- und Spaltennamen mit aussagekräftigen Bezeichnern versehen, um die Lesbarkeit erhöhen. Hat man sich erst einmal an ein bestimmtes Schema gewöhnt, entfällt oft auch das Nachschlagen bzw. Suchen eines Spalten- oder Tabellennamens, denn der ergibt sich dann oft von selbst. Ich weiß also, daß z.B. meine Index-Spalten immer mit Idx_ beginnen und kann so viel flüssiger arbeiten.
Diesen Tip halte ich für fragwürdig. Ein Index ist ein "physikalische" Möglichkeit, den Zugriff auf einen Datensatz über bestimmter Felder zu beschleunigen. Welche Felder einen solchen Index besitzen und welche vielleicht einen gemeinsamen Index haben, sollte mit dem Datenmodell und der Benennung nichts zu tun haben.
Wie würdest Du z.B. ein Feld nennen, dass Teil eines Index ist?
Offensichtlich wird gern der Unterschied zwischen Index und Key Constraint vernachlässigt, beides existiert aber technisch völlig unabhängig voneinander und kann auch so eingesetzt werden.
D.h. es ist möglich, eine Primärschlüsselspalte ohne Index zu verwenden (macht natürlich wenig Sinn). Es ist auch möglich einen Index anzulegen, der zu keinem Key Konstraint bzw. logischen Fremdschlüssel gehört. Das macht je nach Anwendungsfall schon sehr viel Sinn und ergibt sich u.U. erst in einer späteren Lebensphase der Datenbank (Tuning).
Feldnamen sollten primär an der Logik des Datenmodells und am Feldinhalt orientiert sein, nicht an physikalischen Gegebenheiten. Die ändern sich nämlich gern mal und dann kann man mit seinen "Konventionen" ganz schön auf dem Bauch landen.
Jedes RDBMS trennt physikalische Optionen (z.B. in der Create Table Anweisung) von den logischen Optionen.