nicht angemeldet
Hi,
und "nref" bedeutet...? :-)
"Nachrichten-Referenz".
dann wäre "t_nachrichten_referenz" oder z.B. "t_news_ref" deutlich sprechender... Da ich Dir das eigentlich nicht zu sagen brauche, erwähne ich es nur für die Akten und eventuelle Mitleser ;-)
Versteh mich bitte nicht falsch, es ist natürlich euer Bier,
wie ihr die Nomenklatur aufstellt.
Hätte ich diese Tabelle anlegen dürfen, dann hießen die Felder anders.
Meine Verwunderung basierte insbesondere auf Unkenntnis der Tatsache, dass das DB-Layout nicht von Dir stammt. Trotzdem empfehle ich einen Refactoring-Schritt.
Bei meinen in dieses System eingebauten Tabellen habe ich mich aller-dings an die t_/d_-Konvention gehalten, um keine unnötigen Brüche in die Nomenklatur zu bringen.
Konsequenz ist sinnvoll, auch wenn das Ergebnis konsequent sinnarm ist.
Außerdem gibt es zu _meinen_ Tabellen einen ausführlich kommentierten
Quelltext aller CREATE TABLE-Statements ...
Für alle Mitleser: Das ist extrem wichtig. Tabellenstruktur, Bedeutung und Inhalt der Tabelle, Bedeutung und Inhalte der einzelnen Spalten, eventuelle Semantiken (die zwar vermieden werden sollten, aber nicht immer können), Abhängigkeiten mit anderen Tabellen, evtl. Herkunft des Inhaltes, potentielle sowie übliche Statements, Beschreibung wann welcher Index verwendet wird usw. - all das gehört dokumentiert. Idealerweise legt man pro Tabelle eine Datei namens "tabellenname.sql" an, welche in einem allgemein zugänglichen Verzeichnis liegt - und regelmäßig gesichert wird.
Denk aber auch daran, dass mal ein neuer Techniker hinzukommen
kann, ein Unbeteiligter, der das System praktisch "auf den ersten
Blick" verstehen muss.
Ich habe die besagte Firma mehr als nur im Verdacht, daß sie genau das
verhindern will ... :-\
Oder es waren einfach nur Stümper am Werk. Oft ist das auch der Grund, weshalb der Quellcode nicht freigegeben wird: die Entwickler schämen sich dafür.
Diesen Effekt sieht man auch oft bei Leuten, die die rechte Maustaste sperren wollen, um "ihren Quälcode zu schützen" ;-)
Genau der type cast scheint ja das Problem zu sein.
In http://www.mysql.com/doc/M/y/MySQL_indexes.html stand
allerdings m. E. nichts Entsprechendes drin - bisher jedenfalls. ;-)
Hast Du das Problem mal an MySQL geschickt? Sowas gehört eindeutig dokumentiert - bzw. gebugfixt, denn ich unterstelle einfach mal, dass es sich hier um einen Bug handelt. Es gibt IMHO keinen Grund, weshalb ein Index nicht verwendet werden soll, nachdem die zu suchende Konstante(!) einen Typecast erfahren hat.
Ich kann es sogar nachvollziehen. Allerdings sollte das eher ein bug
sein - wenn man die Reihenfolge im Query Optimizer umstellt (erst den
type cast, dann die Index-Entscheidung), sollte es ja kein Problem sein.
Eben...
Cheatah