Nun reicht es mir.
Diejenigen, die mich kennen, wissen wohl, dass ich ein großer Gegner von persistenten Feldern bin. Sobald man diese benutzt, sollte man keine Änderungen mehr an den betroffenen Tabellen der Datenbank machen. Warum? Felder, die man über den Feldeditor des DataSet oder des DBGrid persistent gemacht hat, bekommen Änderungen an der Datenbank nicht mit. Der Programmierer wundert sich dann, warum diese Änderungen in der DB nicht dargestellt werden. Plötzlich werden neue Felder nicht mehr angezeigt, Einstellungen an Feldern nicht übernommen oder das Programm stürzt ab, weil ein Feld in der Datenbank-Tabelle gelöscht oder umbenannt wurde. Natürlich macht das auch Probleme, wenn entsprechende Einstellungen im Source gemacht werden, aber dort hat der Compiler zumindest eine Chance etwas zu bemerken und hervorzuheben. Bei persistenten Feldern "sieht" man einfach nicht, wo der Fehler steckt. Ganz schlimm wird es, wenn man den Feldeditor vom DBGrid und dem DataSet verwendet. Das endet dann wirklich im Chaos.
So, das ist meine Meinung dazu. Ich benutze zur Steuerung der Felder lieber meine eigene Komponente (Feld-Formatierer auf meiner HP). Dann kann ich die Einstellungen sogar zur Laufzeit möglich machen. Aber das ist natürlich Geschmackssache. Auf jeden Fall rate ich jedem, keine persistenten Felder zu verwenden.
Gibts andere Meinungen? (traut euch nur... )

Bei Zugriffsfeldern für DataSets stimme ich dir zu. Bei Columns von DBGrids kann es im Einzelfall aber sinnvoll sein. Wenn z.B. nur bestimmte Felder angezeigt werden sollen.

Auch das ist problemlos über den Source zu lösen.

jasocul hat folgendes geschrieben:

Auch das ist problemlos über den Source zu lösen.

Einfacher ist es aber über die IDE.

mkinzler hat folgendes geschrieben:

jasocul hat folgendes geschrieben: Auch das ist problemlos über den Source zu lösen. Einfacher ist es aber über die IDE.

Ein klares Jain! Es ist bequemer, aber nicht einfacher.
Es scheint nur so. Auch Anfänger sollten in der Lage sein, eine Zeile Code zu produzieren. Mehr ist das nämlich nicht. Dadurch werden von vornherein die oben beschriebenen Probleme vermieden. Und gerade Anfänger in der DB-Entwicklung müssen ihre Tabellen häufig überarbeiten. Die Probleme sind vorprogrammiert. Ich habe schon oft genug feststellen müssen, dass genau durch dieses Vorgehen Schwierigkeiten entstehen. Als Lösung habe ich immer wieder vorgeschlagen die persistenten Felder zu entfernen und plötzlich lief wieder alles.
Außerdem ist es völlig egal, ob das beim DBGrid oder im DataSet eingestellt wird.

IDEs sind dazu da, häufige, unangenehme Arbeiten zu erleichtern ... Denken sollte man immer noch selbst ...

Und gerade durch die IDE wird einem sehr viel Zugang zu seinem Programm versperrt. Und gerade, wenn es um Informationen geht, die nicht offensichtlich zugänglich sind, sollte man immer so viel wie möglichst selbst machen ...

Und zugegeben: Die Delphi-IDE ist in Sachen Property- und Feld-Editoren geht, nicht grad die beste. Und vor allem die Update-Logik und Fehlertoleranz ist UAS* ...

*Unter aller Sau

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin

Aus eigener leidvoller Erfahrung mit persistenten Feldern habe ich mich von selbigen verabschiedet. Stimme jasocul diesbezüglich voll und ganz zu. Hatte an einem fremden Programm auf Kundenwunsch Felder anpassen müssen und durfte mich dann durch sämtliche Table-Feldeditoren quälen, um das auf die Reihe zu kriegen...

So schlimm finde ich die IDE nun auch wieder nicht. Sonst würde ich sie bestimmt nicht benutzen.
Womit du aber eindeutig recht hast, ist folgendes:

BenBE hat folgendes geschrieben:

Und gerade durch die IDE wird einem sehr viel Zugang zu seinem Programm versperrt. Und gerade, wenn es um Informationen geht, die nicht offensichtlich zugänglich sind, sollte man immer so viel wie möglichst selbst machen ...

Wobei der Zugang nicht versperrt wird. Es ist einfach nicht mehr offensichtlich.

@jasocul: Ich hab bewusst "gesperrt" geschrieben, weil die IDE (bedingt durch die VCL) den Zugriff z.B. das Fenster-Handle zulässt, das einem aber nix bringt, wenn man OGL programmiert, da dieses Handle je nach Gutdünken der VCL freigegeben wird.

In Bezug auf die Datenbanken stimm ich Dir aber mit dieser Einschränkung zu; ich bin nur gedanklich etwas weiter gegangen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

OK. OGL habe ich noch nie programmiert. Bin kein Grafik-Spezi. Ich glaubs dir also erstmal.

Da bin ich nach Monaten mal wieder hier und brech gleich nen Gelehrten-Streit vom Zaun *freu*

Hm. Ich bin immer bereit dazu zu lernen, deswegen würd ich Deine Frage, jasocul, gerne mit einer Gegenfrage beantworten:

Wir nutzen eine Datenbank (mysql). In dieser Datenbank hat in einer Tabelle ein Feld die Länge 200. Die Delphi-Anwendung aber darf nur 100 Zeichen davon beschreiben (die volle Ausnutzung der 200 Zeichen ist einer Web-Applikation vorbehalten). Da ich das Feld in der Applikation aus mehreren Forms über DBEdit füllen kann, ist es nur logisch, dass ich die Länge direkt in der Table-Kompo beschränke. Wo aber ist nun der Unterschied, ob ich die Limitierung im Quellcode setze oder im persistenten Feld? Der Aufwand bei einer Änderung der Länge in der Datenbank ist derselbe.

Und um die Frage konkret aus meiner Sicht zu beantworten: Im reinen RAD-Umfeld ist die Verwendung persistenter Felder, gerade wenn man viele Lookups hat, definitiv schneller in der Umsetzung. Das wichtigste ist nur, konsequent vorzugehen: WENN persistente Felder, DANN überall. Damit man IMMER weiss, was geändert werden muss.

Aber ich werde jetzt trotzdem mal eine Software ganz ohne persistente Felder schreiben. Vielleicht komme ich ha doch zu neuen Erkenntnissen

Viele Grüße,

Matthias

@neojones:
Du kannst doch keinen Streit vom Zaun brechen. Dafür bist du doch viel zu nett. Du warst auch nur der letzte Tropfen. Fragen zu dem Problem tauchen regelmäßig im Forum auf.
Du hast insofern recht, dass es bei einem sehr guten Datenbank-Design unerheblich ist, ob man persistente Felder benutzt oder nicht. Schließlich ändert sich dann nichts. Ich stimme dir auch zu, dass man konsequent sein muss: Entweder persistent oder nicht. Aber nur in dieser Kombination funktioniert das Ganze.
Anfänger im DB-Bereich werden das aber nicht hinbekommen. Die Fehler und Fehlersuche ist dort enorm. Damit auch die Entwicklungskosten. Besonders bei Übergabe an einen "neuen" Programmierer. Der "sieht" nämlich nicht, was eingestellt ist. Steht es im Source, ist es offensichtlich. Natürlich weiß ein erfahrener DB-Programmierer, warum eine Änderung auf einer Tabelle sich nicht im DBGrid widerspiegelt. Typisches Phänomen von persistenten Feldern. Aber schön ist das nicht, weil dann erstmal alles überprüft werden muss, wo persistente Felder sein könnten.
Auch die Nutzung eines DataSets oder DBGrids für verschiedene DB-Abfragen, ist mit persistenten Feldern unmöglich. Eine dynamische Programmierung wird dadurch verhindert. Für visuelle Einstellungen benutze ich immer meine Komponente (s.o.). Für spezielle Sachen, wie Eingabe-Beschränkungen (wie in deinem Beispiel), schreibe ich das in den Source oder erweitere meine Komponente.
Ich finde es einfach übersichtlicher, keine persistenten Felder zu verwenden. Wartungstechnisch ist imho auch besser.

Persistente Felder ? Was ist das ? Habe ich noch nie gebraucht. Wo soll da ein Vorteil liegen ? Habe hier ein relativ kompliziertes Standard-Ausgabeformular. Da sind schon 2 Datasets automatisch dabei. Allerdings müssen die SQLs erst konkret besetzt werden. Und zwar von Fall zu Fall anders. Welchen Vorteil sollen diese komischen Felder denn haben ? Ausnahmen wirds schon geben. Wie man hier sieht, können sie aber mehr Ärger verursachen, als sie überhaupt wert sind. Sind das vielleicht noch Überbleibsel aus Uralt-BDE-Zeiten ?

Der einzig sinnvole Einsatz von Datenbankfeldzugriffsobjekten (tolles Wort )ist auch bei (BDE-)TTable-Objekten, wenn man für die Anzeige in DBLookupList/Combo-Boxen die Daten aus mehrerer Felder benötigt. In TQueries natürlich eleganter lösbar.

@hansa:
Hat nichts mit der BDE zu tun.
@mkinzler:
Wer benutzt denn TTable?

jasocul hat folgendes geschrieben:

@hansa: Hat nichts mit der BDE zu tun. @mkinzler: Wer benutzt denn TTable?

Wenn ich nicht irre benutzt TTable die BDE ?

Zitat:

Wer benutzt denn TTable?

Wenn man viele Fragen hier und in der DP liest Einige. Ich würde freiwillig keine BDE mehr nehmen

@Hansa:
Ich bezog das auf die persistenten Felder. Die haben nichts mit der BDE zu tun.
@mkinzler:
Ich möchte nicht in eine Diskussion über das richtige DataSet oder den Sinn/Unsinn der BDE umschwenken. Mir ist die (Nicht-)Nutzung der persistenten Felder schon wichtig, weil dort viele Probleme entstehen (können).
Vielleicht können Anfänger davon profitieren.

Ich arbeite mit persistenten Felder, wo es nur geht.
Vorteile:
1.Schnell: Faktor 10-100 (je nach Anzahl der Spalten)
2.Anpassbar: OnGetText, DisplayFormat, DisplayLabel etc.
3.Bequem: Alles so schön zur Designzeit einstellbar.

Nachteil:
Statisch.

Aber wenn ich eine Applikation neu entwickle, dann ist die DB-Struktur sowieso zu 99% fertig. Die paar Änderungen, die sich während der Implementierung ergeben, machen mir Nichts aus. Zuerst wird doch sowieso immer die DB entworden, dann die Views und Stored Procedures.

Wenn ich eine Anwendung habe, die darauf basiert, das die Daten selbst vom Endanwender anzupassen sind (z.B. CRM Systeme etc.), dann arbeite ich nur mit Metadaten und diversen Layern, die mir erlauben, die Datenstrukturen zu ändern, ohne etwas am Code herumfummeln zu müssen. Im Client stecken dann keine Datasets mehr.

Ich habe nur eine Anwendung, die keine persistenten Datenfelder enthält: Einen Reportgenerator, der die Reportdefinitionen von der Pladde liest. Klar, das der nix mit persistenten Datenfeldern anfangen kann.

alzaimar hat folgendes geschrieben:

Aber wenn ich eine Applikation neu entwickle, dann ist die DB-Struktur sowieso zu 99% fertig. Die paar Änderungen, die sich während der Implementierung ergeben, machen mir Nichts aus. Zuerst wird doch sowieso immer die DB entworden, dann die Views und Stored Procedures.

Das ist ja auch professionell Vorgehen. Und wenn man sich streng daran hält, dürfte es kaum zu Schwierigkeiten kommen. Individuelle Benutzer-Ansichten werden dadurch aber schwierig. Muss aber auch nicht in jedem Fall sein.