Wer mag was mit mir coden?

  • Original von macuser
    Original von gritsch
    Postgre ist overkill und einfaches XML viel zu viel arbeit und wohl nicht auch recht schnell. Was spricht gegen SQLite?


    das gleiche was gegen psql spricht. wenn sich die stuktur ändert hat man ein problem.


    Da braeuchte man dann eine dynamisch erweiterbares Datenbank-Interface.

    Ich geb meine Implementierung aber nicht ohne gutes Geld raus. ;)


    Manfred

  • Ich weiß jetzt nicht, was du in deiner App benötigt hast. Aber da das Ganze ohnehin hintern einem Abstraction Layer liegt, ist es ja auch gerade gleich.

    Wieso sollte ich nicht etwas verwenden, was es schon gibt, gut funktioniert, getestet ist? Zumal ich dann gleich Netzwerkfähigkeit habe und Kompatibilität zu $BSNACHDEINERWAHL.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Also, Filemaker oder so solls ja eben nicht werden. Eher so die Apple Works-Datenbank. Das ganze GUI-Zeugs ist aber eigentlich nicht nötig, das lässt sich auch anders regeln.
    "Wales is the land of my fathers. And my fathers can have it." - Dylan Thomas

  • warum denn XML ???
    du verzichtest doch damit schon mal auf einen großteil der vorteile einer anständigen DB (hatten wir es kürzlich nicht schon mal davon???)

    also um die sache flexibel zu machen würde ich auch auf einen layer setzten, dann kannst du an deine app verschiedene DB's andocken. wäre doch klasse, damit bleibt es dem user überlassen welche datenbank er nutzen will.

  • Original von læng
    Also, Filemaker oder so solls ja eben nicht werden. Eher so die Apple Works-Datenbank. Das ganze GUI-Zeugs ist aber eigentlich nicht nötig, das lässt sich auch anders regeln.


    als wenn du so richtung access gehen willst, dann wirst du wohl um die GUI-Elemente nicht drum rum kommen, oder wie soll der user die app bedienen???

  • Original von wolf_10de
    Original von læng
    Also, Filemaker oder so solls ja eben nicht werden. Eher so die Apple Works-Datenbank. Das ganze GUI-Zeugs ist aber eigentlich nicht nötig, das lässt sich auch anders regeln.


    als wenn du so richtung access gehen willst, dann wirst du wohl um die GUI-Elemente nicht drum rum kommen, oder wie soll der user die app bedienen???


    Zwei Modi:
    1.) Überblick - ne Tabelle (soweit hab ich auch schon was programmiert)
    2.) Browse - da bräuchte man dann sowas wie ne NSMatrix, die aber verschiedene Arten von Views (für jeden Datentyp eine eigene) darstellen kann. Dazu hab ich auch noch Zeichnungen in meinem Englisch-Heft ;)
    "Wales is the land of my fathers. And my fathers can have it." - Dylan Thomas

  • Original von læng
    Ob XML, *SQL oder whatever finde ich übrigens nicht so wirklich wichtig. Das was ich schon hab, hab ich ganz ohne sowas programmiert mit nem eigenen Modell.


    naja wenn es drum geht große datenmengen zu speichern finde ich es schon wichtig, also das ganze soll doch so was wie access geben oder????

  • Nur eine Idee:

    GUI könnte mit Interface Builder zusammengestellt werden
    und als Nib-File gespeichert werden, welche von deinem
    DB App geladen werden kann.

    Die Daten werden per Binding gesetzt ...
    so viel für den Anfang ...

    Ausserdem frage ich mich, welche Features dein App beinhalten sollte?
    Aus macfreakz wurde Apfelbeisser …

  • Original von macfreakz
    Nur eine Idee:

    GUI könnte mit Interface Builder zusammengestellt werden
    und als Nib-File gespeichert werden, welche von deinem
    DB App geladen werden kann.

    Die Daten werden per Binding gesetzt ...
    so viel für den Anfang ...

    Ausserdem frage ich mich, welche Features dein App beinhalten sollte?


    Ja, das mit den NIB_Files hatte ich mir auch überlegt.
    Features? Datensätze (mit Feldern mit verschiedenen Typen) erstellen und durchsuchen. Fertig.
    "Wales is the land of my fathers. And my fathers can have it." - Dylan Thomas