Bilder oder Dateipfade in Access-DB speichern?!

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 31 Antworten in diesem Thema. Der letzte Beitrag () ist von Noyne.

    Bilder oder Dateipfade in Access-DB speichern?!

    Hallöchen Leute,

    ich bin's mal wieder :rolleyes:

    Ich hab' mich mal ein bisschen in die Thematik "Bilder in Access-DB speichern" eingelesen.
    An sich wird ja meist davon abgeraten, die Bilder direkt in die DB zu speichern und lieber nur Dateipfade abzuspeichern.

    Angedacht ist es, zu jedem unsrer Medikament ein kleines Bild hinterlegen zu können.
    Das sind im Moment zwischen 1.100 bis 4.000 Datensätze (je nach Pflegeheim).
    Ich dachte da vielleicht auch daran, die Bildgröße auf 60 x 60 Pixel zu beschränken und sie ggf. zu komprimieren, damit sie nicht ZU groß sind.

    Ich wollte gern mal wissen, ab welcher Menge und Größe von Bildern das schon langsam kritisch wird bzw., ob es selbst mit 1.000 kleinen Bildern schon nicht mehr möglich ist, vernünftig zu arbeiten, weil es die DB zu sehr aufbläht.
    Sollte ich lieber doch irgendwo einen Ordner erstellen und nur die Datenbankpfade in die DB speichern??

    Danke für eure erneute Hilfe ;)
    GLG Noyne
    Your computer is running... You better go chase it! :P :D

    Meiner Meinung nach gehören nur reine Daten in deine Datenbank, selbst wenn es nur ein 1x1px Bild ist, so was gehört nicht in eine Datenbank.

    @Noyne Bei so kleinen Bildchen würde ich die selbst hineinpacken.
    Kaum läuft die Siftware woanders, stimmen die Pfade nicht mehr oder die Bilder sind wech.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Wieso sollte das ganze nicht wo anders funktionieren? Du gibst keine absolute Pfade an, sondern relative.

    @nyone
    ich hab beides schon gemacht. Hat alles vor und nachteile :)

    Ich persönlich arbeite lieber mit Bildern in einem eigenen Ordner einfacher.
    There is no CLOUD - just other people's computers

    Q: Why do JAVA developers wear glasses?
    A: Because they can't C#

    Daily prayer:
    "Dear Lord, grand me the strength not to kill any stupid people today and please grant me the ability to punch them in the face over standard TCP/IP."

    Ich hab auch schon beide Varianten durch.
    Und gelesen habich, es gehöre in die DB, damit alles beisammen ist, dass portabler ist, und auch wg. Zugriffsrechten.
    Vom typDataset her ist eine Verwaltung der Pfade günstiger, weil dann kann man 10000 Datensätze auf einmal laden, und binden kann man eine Picturebox einfach an eine Url, sogar aussm Internet. Gugge Keine Strings in die File-Listbox!.
    Sind die Bilder hingegen inne DB, muss man dafür eine ganz spezielle Steuerung coden, die immer genau ein Bild lädt und zur Anzeige bringt.
    Eventuell auch die Bilder-Tabelle abtrennen, dann kann man die anneren Daten weiterhin stumpf nach Schema F laden.
    Und will man viele Bilder gleichzeitig anzeigen können, muss man noch viel mehr optimieren (Cashing, Thumbnails), also das wird ein recht spannendes Programm-Modul.

    Erstmal danke für eure Antworten ;)

    ErfinderDesRades schrieb:

    Und will man viele Bilder gleichzeitig anzeigen können
    Sowas brauch' ich nicht. Es soll zu jedem Medikament immer nur ein Bild gespeichert und angezeigt werden.

    ErfinderDesRades schrieb:

    Sind die Bilder hingegen inne DB, muss man dafür eine ganz spezielle Steuerung coden, die immer genau ein Bild lädt und zur Anzeige bringt.
    Und genau sowas wöllte ich gerne machen, muss ich ehrlich gestehen. Ich glaub' nicht, dass bei kleinen Bildern die DB so arg anschwillt, dass es unheilig wird.

    ErfinderDesRades schrieb:

    Eventuell auch die Bilder-Tabelle abtrennen, dann kann man die anneren Daten weiterhin stumpf nach Schema F laden.
    DAS finde ich auch sehr gut!! Ich werd' das so einbauen.

    Wenn ich was genaueres brauche, dann würde ich mich wieder melden ;)
    Danke nochmal ^^

    GLG, Noyne
    Your computer is running... You better go chase it! :P :D

    Noyne schrieb:

    Es soll zu jedem Medikament immer nur ein Bild gespeichert und angezeigt werden.
    20.000 Medikamente und 20.000 Bilder
    oder
    20.000 Medikamente und 1.000 Bilder?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    ErfinderDesRades schrieb:

    Problematisch ist das Anschwellen des typisierten Datasets.
    Gut, dadrüber mach' ich mir 'ne Platten, wenn ich es jemals umbaue, weil im Moment arbeite ich ja ohne typ. DataSet ...

    RodFromGermany schrieb:

    20.000 Medikamente und 20.000 Bilder
    Rein theoretisch so, ja ...
    Rein praktisch wird es aber wohl eher so:

    RodFromGermany schrieb:

    20.000 Medikamente und 1.000 Bilder
    sein, weil ich befürchte, dass das kaum gemacht wird, aber die Möglichkeit soll halt gegeben sein, bei einem Medi ein Bild einzufügen ...
    Your computer is running... You better go chase it! :P :D

    weil im Moment arbeite ich ja ohne typ. DataSet ...
    Ohjeh!
    Du prodzuierst grade ein unwartbares Produkt.
    Jeder annere Progger, der mit typisierten Datenmodellen umzugehen gelernt hat, wird statt Wartung immer sagen: "Neuschreiben!"

    Es ist wirklich wirklich keine gute Idee, sich untypisiert durchzuwursteln, und - "ach das Problemchen kriegen wir auch noch, und das - naja komm: auch noch..."
    Und irgendwann: "ooh - jetzt simmer schon so 'weit' gekommen, jetzt ist zu spät"

    Die Hopis (sagt man) sagen dazu: "Wenn du merkst, dass du ein totes Pferd reitest - steig ab"

    Womit gesagt ist:
    "Spätheit" ist gar kein Entscheidungs-Kriterium - ein totes Pferd funktioniert nicht, das wird sich erweisen - so oder so.
    "Spätheit" spielt allenfalls eine Rolle, wie schlimm es wird, nämlich je später desto schlimmer.

    €dit: Jaja, ich weiß: Ist nicht mehr zu ändern, Termindruck, beim nächsten Mal vielleicht

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    @ErfinderDesRades
    Ich weiß schon seit ich das erste Mal drüber nachgedacht habe, auf typ. DS umzusteigen, dass das Pferd tot ist. ||
    Nur muss ich ehrlich gestehen, ich komm' grad nicht zurande, die gesamte Datenbank, die ich hier habe, vernünftig in ein typ. DataSet umzuwursteln, weil ich an der Original-Datenbank leider so viel umbasteln muss, dass ich einfach nicht weiß, wie ich es vernünftig und richtig in ein DataSet umbauen kann. Ich hab' mir deine Videos und Tuts fast alle durchgeguckt und auch schon was probiert, was ich aber wieder verworfen habe, weil ich nicht wusste, ob es so funktioniert oder nicht ...
    Ich krieg' es im Kopf einfach nicht umgebaut, weil ich mir nicht vorstellen kann, dass es funktioniert. Ich bräuchte einfach mal jemanden, der sich das gesamte Problem mal anhört oder durchliest und mich in die richtige Richtung schubst. Du und sonne75 habt ja mal versucht, mich über den Pfad zu führen, nur bin ich euch auf dem Weg weggerutscht und den Abhang runtergekullert ... Dann bin ich wieder zurückgelaufen, den Hang wieder hoch und stehe jetzt mehr oder weniger wieder am Anfang und reite das tote Pferd :D ...

    EDIT: Ich hatte eben eine Idee bezüglich des typ. DS ... Ich versuch' das mal, mal sehen, ob es geht.
    Your computer is running... You better go chase it! :P :D

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Noyne“ ()

    ich sag ja immer: Ohne DB entwickeln. Dann musst du sie auch nicht umbauen.
    Tja, und ohne typDataset können wir nichtmal übers Datenmodell reden - naja- vlt. kannst du Bildle von iwelchen DB-Diagrammen anhängen, aber eine angehängte Dataset-Xsd-Datei wäre feiner, weil die kann man im VS öffnen, und richtig reingugge.

    ErfinderDesRades schrieb:

    Ohne DB entwickeln. Dann musst du sie auch nicht umbauen.
    Ich hab ein vorhandenes Projekt weiterbearbeitet und es soweit fertig gehabt, dass es halbwegs funktionierte ... Und erst DANACH bin ich auf die Idee mit dem DS gekommen ... Da war dann irgendwie nix mehr mit "ohne DB" ... Hätt' ich das Projekt jungfräulich aufgezogen, wäre es garantiert ohne DB gewesen ...
    So wie ich die xsd-Datei fertig hab, kann ich sie ja mal hier ranhängen ...
    Your computer is running... You better go chase it! :P :D

    ui - das sieht ja wüst aus.
    Ich hab mal alle Tabellen kollabiert, und so zurechtgeschoben, dass die Relationen kreuzungsfrei verlaufen - sieht eiglich ganz ok aus, ausser dass 2 parallele Relationen Arzt->Einnahmeverordnung existieren - das ist glaub nicht i.O.

    Leider hab ich ein technisches Problem mitte Forum-Software, und kann daher das Bild nicht anhängen. Habs dir gemailt, wenn du was dazu sagen willst, kannst dus ja anhängen

    Ach, und noch sehr eigenartig finde ich die ebensolche Doppel-Relation Dosiereinheit->MedikamentNeu.

    Also sehr komisch: Ein MedikamentNeu hat gleich 2 Dosiereinheiten, aber ein Medikament garkeine ??

    Mir unklar überhaupt, warums 2 Tabellen gibt: Medikament und MedikamentNeu

    €dit: je länger ich drauf-guck...
    ZB die Relationen Arzt->Bestellung, Bewohner->Bestellung sind redundant.
    Bestellung ist bereits über die Verordnung mit Arzt und Bewohner in Beziehung gesetzt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    ErfinderDesRades schrieb:

    Ich hab mal alle Tabellen kollabiert, und so zurechtgeschoben, dass die Relationen kreuzungsfrei verlaufen
    Ich komm mit den Überschneidungen klar :D Aber so zurechtgeschoben sieht es schon schöner aus ;)

    ErfinderDesRades schrieb:

    ausser dass 2 parallele Relationen Arzt->Einnahmeverordnung existieren - das ist glaub nicht i.O.
    Gut, wenn du die Tabelle aufklappst, siehst du, dass da bei der Einnahmeverordnung eine "EVO_verordnet_ID" und eine "EVO_abgesetzt_ID" drin sind. Das sind beides Arzt-IDs, je nachdem, welcher Arzt das Medikament verordnet bzw. abgesetzt hat. Das müssen nicht zwingend dieselben sein. Deswegen sind da zwei Relationen zur Arzt-Tab drin ...

    ErfinderDesRades schrieb:

    Doppel-Relation Darreichung->MedikamentNeu.
    Die Medikamente_NEU und die Dosierungseinheit haben ähnlich wie Arzt<->Einnahmeverordnung eine Doppelrelation, weil ich im Medikamentendialog zwei Comboboxen habe: eine, die die richtige, reguläre Dosierungseinheit anzeigt und eine, die eine abweichende Dosierungseinheit angibt.
    Mal ein Beispiel: Insulin hat zum Beispiel an sich die Dosierungseinheit "ml" für Milliliter. Aber kein Diabetiker spritzt sich das in Millilitern in den Körper. Um das anzuzeigen, hat man eben festgelegt, dass zusätzlich noch angegeben werden soll, wie viele "IE" (Insulineinheiten) das sind und dazu ein Umrechnungsfaktor von 0,01, sodass die Rechnung zustande kommt: "20 IE = 0,2 ml" ... Deswegen hat die Medikament_NEU-Tab auch eine "MED_DOE_ID" für die normale UND eine "MED_DOEAbw_ID" für die abweichende Dosierungseinheit.

    Ich muss auch ehrlich sein, dass ich nicht wüsste, wie ich das sonst angeben soll ...

    ErfinderDesRades schrieb:

    Habs dir gemailt
    Hab's gesehen ;) Ich häng das Bild mal mit hier an...

    ErfinderDesRades schrieb:

    ZB die Relationen Arzt->Bestellung, Bewohner->Bestellung sind redundant.
    Die Bewohner-Bestellung hab ich reingenommen, damit ich leichter Datensätze zählen kann ... Ich hoff ja mal, dass ich die jetzt wieder rausnehmen kann ...

    Oh, und apropos "rausnehmen": Wenn die Medikament_NEU mal komplett fertig ist, fliegen die Medikament- und die Masseinheit-Tab ebenfalls raus, weil die Quatsch sind. Im Moment hab ich die aber noch, weil in der Medikament-Tab noch Daten sind, die wir brauchen könnten ...
    Bilder

    • AB_DS-Bild.jpg

      95,81 kB, 800×511, 356 mal angesehen
    Your computer is running... You better go chase it! :P :D