Best practice - nahezu statische Entity

Re(2): Best practice - nahezu statische Entity

zeddicus — Sat, 31 Dec 2016 21:20:34 GMT

Das Thema kommt im Data Warehousing öfter vor, dort bezeichnet man es mit dem
Begriff "inferred member".

Vielen Dank, allein mit dieser Info kann ich schon viel anfangen, da ich endlich weiß nach was ich suchen muss. Das ist echt wieder so eine Frage gewesen wo google aufgrund des fehlenden Begriffs nur Kacke liefert

Re: Best practice - nahezu statische Entity

hhetl — Fri, 30 Dec 2016 14:39:52 GMT

old school: unbekannte ID per Trigger/alternativer Prozedur "on the fly" in der Keytabelle anlegen.

neu und hip: statt IDs (= rgendein Integer, der per Autoinkrement generiert wird) einen Hash über die eindeutigen Felder (Key) verwenden.

Das Thema kommt im Data Warehousing öfter vor, dort bezeichnet man es mit dem Begriff "inferred member".

cheers
h

Re(2): Best practice - nahezu statische Entity

zeddicus — Fri, 30 Dec 2016 00:12:18 GMT

generell nix, der index besteht ja auch. Aber als join im view zu teuer. Als join per function ginge es, als join im entity wieder zu teuer. habs jetzt im moment als static dictionary mit timestamp und self refresh das geht ganz gut

Re: Best practice - nahezu statische Entity

Sir Hondo — Thu, 29 Dec 2016 22:50:27 GMT

Entschuldige falls ich da jetzt eventuell Mist rede, vielleicht hab ich die Frage nicht verstanden, aber was spricht gegen einen ganz normalen Index auf die ID in ID_Info?

Ich geh jetzt mal davon aus, dass die ID eindeutig ist oder zumindest stark einschränkt.

Dann halt ganz normal joinen.

Re: Best practice - nahezu statische Entity

mko — Wed, 28 Dec 2016 13:11:58 GMT

Ich würde die Daten mittels Dictionary beispielsweise in einem MemoryCache halten. Das ist sicher kein Fehler, wenn die Datenmenge nicht zu groß ist. (Locking beim Befüllen nicht vergessen.)

Best practice - nahezu statische Entity

zeddicus — Wed, 28 Dec 2016 08:45:39 GMT

Ich hoff ich mach das jetzt einigermassen verständlich

Also, ich bastel zur Zeit mit EF6 und einer MVC Applikation rum, Database First, backend ist postgresql.

Ich hab jetzt x Tables mit sehr vielen Records wo mit einer ID gearbeitet wird, die haben teils sehr (>10^8) viele rows, das passt auch so, und es gibt eine Table (nennen wir sie ID_Info) wo dann diverse Infos zu der ID sind. Diese Table ist nahezu statisch, es tut sich da drin vielleicht alle 14 Tage was. Ich kann die ID in der ID_Info allerdings nicht zum foreign key in den anderen machen, da nicht sichergestellt ist dass der Eintrag vor einem in den anderen Tables kommt.

Diese Anomalie (also dass es in Table_x einen Eintrag mit ID abc gibt bevor einer mit dieser ID in ID_Info erzeugt wird) ist generell kein Problem.

Nun muss ich aber eben im Programm hie und da die Details aus ID_Info zu einem Table_x entity zuordnen.

Generell will ich die Datenbank nicht unnötig belasten, da ohnehin schon seeeehr viele reads/writes passieren.

Überlegungen:
* statischer join via view - imho zu teuer, da die entity generell oft verwendet wird, die Zusatzinfos aber nicht
* computed property via zugriff auf die ID_Info entity und manuellem matching - ev. sogar noch teurer?
* ID_Info alle x Stunden auslesen und in einem statischen Dictionary speichern welches von einer computed property ausgelesen wird - wär meiner Überlegung nach jetzt wohl am günstigsten?

* ?

Zusatzinfo:
Es entsteht kein Problem wenn die Daten für einen neuen Eintrag in ID_Info erst ein paar Stunden später verfügbar sind (falls wer wegen der Verzögerung Probleme sehen würd)