Laden...

Forenbeiträge von Sera Ingesamt 285 Beiträge

22.07.2011 - 15:53 Uhr

Zitat von: Add/Attach and Entity States
Finally, you can add a new entity to the context by hooking it up to another entity that is already being tracked. This could be by adding the new entity to the collection navigation property of another entity or by setting a reference navigation property of another entity to point to the new entity. Ist zwar aus EF4.1 zitiert gilt aber für EF4.0 genauso da ersteres darauf basiert. Der fette-Teil trifft bei dir zu.

Das Verhalten macht mMn durchaus Sinn denn somit wird bei SaveChanges das Objektmodell mit der DB synchron gehalten.

Danke für den Versionshinweis. DbContext ist genau das, was ich gesucht habe und dieses Verhalten auch unterbindet. Mittlerweile benutze ich 3 verschiedene DLL's (EF Standard, POCO, DbContext), um für verschiedene Szenarien die passende Funktionen zu benutzen.

20.07.2011 - 23:56 Uhr

Ist gelöst, danke an alle.

Der Weg mit dem State check bzw. mit einem Reset des ObjectContexts funktioniert zwar, jedoch unnötige Coderedundanz durch die DAL Methode, die alle Properties kopiert.

Habe den redundanten Code gelöscht, und die Methode beinhaltet, neben dem Check der vorhandenen Properties, eigentlich nur noch mehr die SaveChanges() Methode. Keine Ahnung, ich sage es ist Geschmackssache.

20.07.2011 - 22:14 Uhr

@gfoidl

Wollte gerade ein Kommentar von dir aus einem anderen Thread zitieren (POCO und Unabhängigkeit). Da es sich ja um POCO's handelt, sollte dieses Verhalten für diese nicht zutreffen. Speziell dann nicht, wenn diese POCO's in einer externen DLL benutzt werden, die vorab den Graphen aufbauen und zur weiteren Bearbeitung an die DAL übergeben. Eine Referenz zu setzen (fetter Teil) funktioniert nur bequem, wenn tatsächlich zuvor einmal gespeichert wurde.

EDIT: wenn ich xxMUROxx's Tipp verwende ist das natürlich kein Problem, nur wird es unübersichtlich.

@unconnected

Die Methode gibt entweder eine neue City zurück oder eine bereits in der DB angelegte, ich verwende nicht die ID als Rückgabeparameter, wenn ich direkt via Property die Entity Referenz setzen kann. Da ist es egal ob ich ein neues Objekt anlege, da "city" dann im Heap neu referenziert wird durch das zurückgegebene Objekt der Methode.

Übrigens, ja es stimmt, daß Context "München" kennt, aber nur wenn "München" nicht neu angelegt wurde. Wenn München neu angelegt wird, dann überprüft die Methode im DAL, ob München bereits vorhanden ist. Der hier von mir gezeigte Code funktioniert in einer externen DLL nicht, da dort nur die POCO's angezeigt werden. GetCityEntity ist private im DAL verankert. Nicht nur der Maier wird 2x angelegt, sondern auch München, wenn ich nicht neu referenziere. Kranke Logik.

20.07.2011 - 21:42 Uhr

Eine Methode erstellen, die den Connectionstring übergibt und diesen dann an den ConnectionString Paramter des Context Constructors übergeben.

20.07.2011 - 21:22 Uhr

verwendetes Datenbanksystem: <SQL Server 2008>

Hallo,

Ich beobachte derzeit ein merkwürdiges Verhalten des EF 4.0.

Folgendes Problem:


Customer customer = new Customer();
customer.Name = "Maier"

City city = new City();
city = GetCityEntity("München");

customer.City = city; // Die City Navigation Property greift wohl irgendwie auf den Context zu

context.SaveChanges();

Und tatsächlich wird dieses Objekt in der DB abgelegt, ohne AddObject des Contexts selbst zu benutzen. Ist das nicht merkwürdig? Kann man dieses Verhalten unterbinden? Ich arbeite übrigens mit POCO. Proxy oder Tracking zu deaktivieren bringt nichts. Normalerweise wird der unten angezeigte Code aus einer externen DLL aufgerufen. Nur die POCO Klassen sind für diese sichtbar, wo der Customer als Parameter an die DAL DLL übergeben wird.

2 identische Datensätze werden mit diesem Code angelegt:


Customer customer = new Customer();
customer.Name = "Maier"

City city = new City();
city = GetCityEntity("München");

customer.City = city; // Die City Navigation Property greift wohl irgendwie auf den Context zu

context.Customers.AddObject(customer); // Doppelter Maier

context.SaveChanges();

27.07.2010 - 20:45 Uhr

Ich nehme an, daß jeder Task als Entität initialisiert wird, somit ist es unmöglich, daß 2 gleiche Aufgaben in der DB Tabelle existieren. Außer beide User legen die gleiche Aufgabe neu an und du fragst das nicht explizit ab, ob bereits diese Aufgabe exisitert.

Willst du die exakte Reihenfolge einhalten, musst du alle nachfolgenden Tasks "sperren". Ebenfalls explizit.

Sonst Implementation via Isolation oder Optimistic Concurrency in EF.

Klicke dafür im Modelviewer auf eine Property einer Entität. Im Property Viewer siehst du den Eintag "Concurrency Mode". Das stellst du auf "Fixed". Habe dafür die DateTime Spalte der Tabellen genommen, da die letzten Änderung immer dokumentiert werden muss. SaveChanges baust du in einen Try/Catch Block ein.


try {
m_context.SaveChanges();
}
catch ((OptimisticConcurrencyException ex)
{
      throw new EntityLockedException();
}

24.07.2010 - 06:05 Uhr

Was du suchst ist glaube ich der ObjectStateManager

zu finden :

  
using (ShopTestEntities context = new ShopTestEntities())  
{  
      var addedEntities = context.ObjectStateManager.GetObjectStateEntries(System.Data.EntityState.Added);  
}  
  

genial!!! Danke!

var linkedProduct = context.ObjectStateManager.GetObjectStateEntries(System.Data.EntityState.Added)
.OfType<Product>.First/Where.... etc.

Die temporären Entity Keys matchen alle korrekt und es ist nun verdammt schnell.

23.07.2010 - 11:50 Uhr

Wie wahr. Dennoch eine Subtechnologie von ADO.NET.
Soll Heissen? Aussedem benutzt EF ADO.NET nur, ist keine SubTechnologie.

Wenn du Abfragen auf den DataContext machst werden hier Sql-Queries generiert und gegen die DB geschickt.
Wenn also ein Produkt mit der Description "Lotion" in der DB existiert, wird es gelesen.
Wenn du noch keines in die DB geschrieben hast, kann auch noch keines herauskommen.

Ja, nur wo wird die Entität gespeichert, wenn diese mit AddObject dem Set hinzugefügt wird? Das EF kann ja auch nicht zaubern, irgendwo müssen diese Entitäten, die noch nicht in der DB gespeichert sind doch zu finden sein.

22.07.2010 - 17:18 Uhr

Du hast scheinbar eine ganz falsche Vorstellung von dem was Du da machst, bzw wie EF funktioniert.

Wie wahr. Dennoch eine Subtechnologie von ADO.NET.

Du musst nicht die Entitysets einlesen um abfragen auf die DB zu machen.
Du kannst auch per Context mit LinQ abfragen ob ein Entity ( mit bestimmten Kriterien ) exsitiert.

Ich frage dich, wie soll das funktionieren, wenn ich vor mir die context Variable habe?
Intellisense zeigt alle Entitäten und diverse Methoden, jedoch nichts in deiner Richtung. Bitte um ein Beispiel.

Wie sieht es damit aus?


using (ShopTestEntities context = new ShopTestEntities())
            {
                 bool exists = context.ProductSet.Any(p => p.Description == "Lotion");
            }

Was natürlich nicht für TRUE funktioniert, solange SaveChanges nicht ausgeführt wurde.

22.07.2010 - 09:12 Uhr

verwendetes Datenbanksystem: <SQLServer 2008>

Ich möchte gerne per LINQ auf die Entitysets zugreifen, ohne vorher das mit der Methode SaveChanges zu bewerkstelligen.


            using (ShopTestEntities context = new ShopTestEntities())
            {
                Product product = new Product { Description = "Lotion" };
                Order order = new Order { Product = product };
                
                //ProductSet.Count() ist 0!   Auch Order Count = 0             

                context.SaveChanges();

                //ProductSet.Count() ist 1!   Wie auch Order

            }

Hier wird standardgemäß das Produkt initialisiert und danach in eine Order Entität gespeichert. In der gleichen Methode zur Laufzeit soll abgefragt werden, ob es "Lotion" als Produkt bereits gibt. Führe ich SaveChanges aus, so kann ich per Linq das ProductSet abfragen, geht problemlos. Nur möchte ich SaveChanges erst am Ende (wenn alle Entitäten grundlegend initialisiert wurden) ausführen und verstehe nicht, warum man nicht vor dem persistieren in der DB, bereits vorzeitig dies im Speicher abfragen kann und nicht erst nach SaveChanges.

Wie arbeitet EF bei SaveChanges? Wo sind die Einträge vor dem Ausführen der Methode gespeichert, wenn nicht in den jeweiligen Listen?

21.06.2010 - 12:30 Uhr

Tippfehler.
EF Version 4

Der SQL Profiler bestätigt das, was ich bereits schon vorhin gepostet habe. Ab dem 2.ten Durchlauf werden exakt die selben SELECTS aufgerufen, nur die Dauer ist eben weitaus geringer.

Habe mich durch einige Webseiten durchgewurschtelt und gesehen, daß eine quasi In Memory Datenbank mit EF Zugriff realisiert wurde. Quasi eben. Serialisierte POCOs werden deserialisiert und dem EF Layer übergeben. Bedeutet, daß ich in 2 verschiedenen Layern (EF und eigenes Repository für In-Memory) dieselben Objekte anlegen darf. Dachte eben, daß das EF die Daten einmalig mit NoTracking und no deferred loading in den Speicher legt und keine weiteren Zugriffe auf die DB benötigt, und die Abfragen über L2O weitergeführt werden.

Denn beim EF (welche Version eigentlich) kenn ich es so, dass man sämtliche DB-Aktivitäten explizit anstoßen muss. Das war eine bewusste Designentscheidung vom EF-Team - daher würde mich wundern, wenn da noch irgendwas im Hintergrund läuft.

Was man in den context Optionen einstellen kann. Im Hintergrund läuft ja nichts, nur eben wenn man eine Abfrage erneut im selben context anstößt.

20.06.2010 - 22:31 Uhr

Im Activity Monitor unter dem Abschnitt "Prozesse". Zwar keine I/O Aktivität, dennoch Zugriff auf den SQL Server. Wahrscheinlich hat das mit Precompilation zu tun.

Task State => RUNNING
Command => SELECT

scheint in jedem Durchlauf auf. Verschwindet nach Beenden des Programms.

mit ToList und einer foreach Schleife auf das neue Objekt gibts natürlich keine Aktivität.

20.06.2010 - 18:39 Uhr

[...]nur fehlen mir dann die Relations über mehrere Tabellen.
Include kennst du aber? Siehe z.B.
>

Gruß,
dN!3L

Ja, ändert jedoch nichts am eigentlichen Problem. Auch wenn ich alles explizit lade, ist nicht alles wirklich offline verfügbar, wie sonst bei Dataset & co. Mit Include gibts immer noch Aktivität während des Monitoring.

20.06.2010 - 16:29 Uhr

verwendetes Datenbanksystem: <bSQL Server 2008>

Ist es möglich, daß nach dem ersten Durchlauf die gelesenen Daten über EF (kein eSQL) quasi im Speicher bleiben? Zwar werden die Daten nach dem 2. Durchlauf schneller gelesen, dennoch zeigt der Activity Monitor im SQL Server diverse Aktivität.
Meine derzeitige Lösung ist es mit .ToList() dies zu umgehen, nur fehlen mir dann die Relations über mehrere Tabellen. Über L2O würde ich dann explizit in memory auslesen.

Danke für jeden Lösungsvorschlag.

28.03.2010 - 20:17 Uhr

So, ist gelöst, ob es so perfekt ist oder nicht

ObjectQuery<DbDataRecord> returnObject = constructionFacility.CreateQuery<DbDataRecord>(strQuery)

28.03.2010 - 19:35 Uhr

so, ein wenig detailierter


var returnObject = constructionFacility.CreateQuery<???>(strQuery)

Was gehört anstatt den ??? wenn das Objekt nicht materialisiert werden kann?

27.03.2010 - 00:17 Uhr

verwendetes Datenbanksystem: <SQL Server 2008>

Ich wundere mich über den Rückgabetype bei dieser Abfrage mittels eSQL, die im Buch "Programming Entity Framework" zu finden ist:


SELECT c.Title,oa.FirstName, oa.LastName,
        oa.Street1, oa.City, oa.StateProvince
FROM PEF.Contacts as c
JOIN PEF.vOfficeAddresses as oa
ON c.ContactID = oa.ContactID

Ein Entity Objekt kann es auf keinen Fall sein, logischerweise. Generiert EF zur Runtime einen neuen Typen ala einem "quasi" View?

so wie

contextObjekt.FirstName
contextObjekt.LastName
contextObjekt.Street1
..... und der Rest der Parameter in der Abfrage,

Oder gibt es keinen Rückgabetyp und ich muss mit ".Include" arbeiten?

Hochgepriesen wurde das Buch, nur ein konkretes Beispiel gibt es nicht.

13.03.2010 - 14:45 Uhr

danke, yield war mir neu

13.03.2010 - 10:12 Uhr

verwendetes Datenbanksystem: <SQL Server 2008>

Der DataReader läuft doch per "Forward Cursor" die Liste durch.
In der while Schleife kann ich bequem auf die Daten des aktuellen Eintrags zugreifen.

Nun habe ich eigene Entities (als Klassen) im DAL, und finde keine Lösung, diese einzeln zu laden, ohne den gesamten Datenbestand (ala DataTable) im Voraus zu speichern.

Der übliche Weg über den DataReader


while(dr.Read())
{
       att1 = dr["Att1"];
       att2 = dr["Att2"];
       att3 = dr["Att2"];
}

Hier das Problem mit dem Entity


while(dr.Read())
{
       Entity.att1 = dr["Att1"];
       Entity.att2 = dr["Att2"];
       Entity.att3 = dr["Att2"];


}

Natürlich wird das Entity mit den Daten initialisiert, aber kann in der Schleife nicht das Entity zurückgeben. Nur um im BLayer damit arbeiten zu können, brauche ich den gesamten Datenbestand (zumindest 1x Zugriff). Wenn ich jedes Entity in eine List adde und diese List zurückgebe, habe ich das gleiche Problem wie mit dem DataTable. Eine Idee war, das initialisierte Entity über einen Eventhandler zurückzugeben. Der BLayer bekommt so die einzelnen Entities ohne grobe Speicherauslastung. Finde das unsauber.

Kennt jemand von euch einen besseren Ansatz? Danke.

16.07.2009 - 20:01 Uhr

Klar, dn. Nur ist es nicht mein Code, Events werden aus fremden Threads gestartet und der Progger denkt das geht. Wäre eine Idee gewesen und ich in meiner Motivation eine Background Worker Geschichte hingepfuscht, da diese gerade so schön reinpasst.

16.07.2009 - 19:52 Uhr

So, ist gelöst. Backgroundworker als Wirt.

16.07.2009 - 19:39 Uhr

Wofür Code? Ich hab ein Crossthreading Problem. Ein Thread soll ein Control meines MainThreads modifizieren. Sieht nach Async Probs aus.

Will nicht offensiv wirken, dn, aber dennoch danke für deine Hilfe.

16.07.2009 - 19:21 Uhr

ok, ist mir auch noch nicht geholfen.

Stimmt immer noch etwas nicht.

DLL

Threadmethode
Eventhandler

Mainform

Subscriber des Events

Thread delegiert "Ich bin fertig" an subscriber.

Mainform registriert, daß Thread ein Event geschickt hat. Nun will ich das Label innerhalb der Eventmethode aktualisieren. Stillstand! Endlosschleife -> IsAlive = true

Ich muss also das Label per Invoke füllen?

16.07.2009 - 19:13 Uhr

Die Threadmethode hat einen Eventdistributor inkludiert, der das Event "Ich bin fertig" an seine Subscriber liefert.

Ein Subscriber ist die Mainform selbst, wo ich ein Label in dieser Methode fülle. Ich habe den Eventteil gelöscht und nun funktioniert die IsAlive Abfrage.

16.07.2009 - 19:09 Uhr

hi dn,

Hab es getestet, ja das geht. Ich hatte ein Event gestartet und auf die Mainform delegiert. Das war der Grund. Muss ich unbedingt die Main Form invoken um das zu umgehen? Main Thread != DLL Thread.

16.07.2009 - 18:58 Uhr

Eigentlich sollte ein Thread beendet werden, nachdem alle Befehle in der Threadmethode abgearbeitet wurden. Trotzdem habe ich eine while(x.IsAlive) Abfrage, die leider gegen unendlich geht. Warum wird IsAlive nicht auf "false" gesetzt?

13.01.2009 - 17:30 Uhr

verwendetes Datenbanksystem: <SQL Server 2005>

Ich habe auf Windows Server 2008 umgestellt, der einen SQL Server 2005 rennen hat.
Nach der Programmierung eines SSRS Moduls, bekomme ich korrekt das Ergebnis angezeigt. Will ich aber diesen Report downloaden, muss ich mich einloggen. Kann mir jemand bei diesem Authentifizierungsoroblem helfen, um dieses Login zu umgehen?

06.08.2008 - 13:39 Uhr

Mir kommt mal so ne Idee.

Bist du sicher dass du die ganze Milliarde Daten immer brauchst zum Arbeiten, oder stellen die nur eine Art Archiv dar nach einer gewissen Zeit. Falls das der Fall, kannst du mit einer Archivierungstabelle arbeiten, die du nachts füllst. Die Benutzer arbeiten dann nur auf einer aktuellen Tabelle mit den Records der letzten x Tage. Wollen sie tiefer suchen, dann muss die Archivtabelle herangezogen werden und es dauert länger.

Vorteil: der Satz an Daten der letzten x Tage bleibt schlank, und du hast somit keine Performanceeinbussen. Dies ist ein Prinzip, das sehr oft verwendet wird bei grossen Datenmengen.

Danke, gute Idee mit den Archivtabellen.

Und die Milliarden sind nur der gesamte Datenbestand. Geht nur darum, daß nicht paar Inserts pro Tag Schwierigkeiten machen sollen.

06.08.2008 - 13:37 Uhr

@Xynratron

Wenn es nur um diese Eigenschaften geht, dann ist es schon ein bisschen heftig. Da kann man bis auf die Indizes auf diverse SQL Performance Gschichterln verzichten.

Naja, oben hatte ich ja Eckpunkte aufgeführt. Ich würde an deiner Stelle mal ein Testsystem aufbauen und die wirklich auftretenden Performance-Unterschiede bei wenigen und vielen Daten ansehen und dann weiter entscheiden.

🙂

Xynratron

Edit: präziser formuliert

ja, testsystem aufzubauen mit altem datenbestand würde funktionieren, was ich wohl auch machen werde.

06.08.2008 - 09:30 Uhr

@phlekk

Der Haupteil wird Nachts durchgeführt, was keinen stört. Am Tag jedoch befürchte ich Leistungseinbußen in Bezug auf die Benutzer. Und ein Insert kann schon bei diesen Datenmengen lästig sein, da asynchrones Arbeiten ohne Insertresultat unmöglich ist.

06.08.2008 - 09:27 Uhr

Der hohe Speicherbedarf sind die Nachteile vom GC. Vor allem Strings werden erstellt

Der hohe Speicherbedarf kommt dadurch zustande, dass ich alle Datensätze auf einmal in ein Dataset lade.

Da bei einem Kunden die Meldung kam "Hauptspeicher nicht ausreichend" hab ich die maximale Datasetgröße nun auf 500 MB beschränkt.

Grüße Bernd

Du lädst also zuerst alle für den Insert benötigten Daten in eine DataTable und führst somit den Insert als Gesamtes aus? Arbeitest du dabei mit dem TableAdapter?

06.08.2008 - 09:25 Uhr

@Xynratron

Wenn es nur um diese Eigenschaften geht, dann ist es schon ein bisschen heftig. Da kann man bis auf die Indizes auf diverse SQL Performance Gschichterln verzichten.

05.08.2008 - 10:56 Uhr

Hallo,

Dann müsste deine Datenbank bei gleichmässiger Insert Verteilung 31 Inserts pro Sekund schaffen. Ich denke das wird zu einem Problem führen

Das halte ich allerdings für ein Gerücht. Hier gerade an meinem langsamen Entwicklungsrecher getestet und ich schaffe 3000 Inserts/s.

Auch wenn meine Test-Tabelle natürlich ein Scherz (nur ein Autoinc + nvarchar für Daten) ist, selbst bei größeren Tabellen und mehreren Überprüfungen der Daten etc. denke ich dass eine entsprechende Maschine selbst bei 150 Inserts (= 1Mrd / 250 (tage) / 8 (Arbeitsstunden) / 60 / 60) sich dann doch nur langweilt.

🙂

Xynratron

Interessant hier ist, wie lange deine 3000 Inserts/s linear bleiben.

01.08.2008 - 17:30 Uhr

Ein SQL Server 2005 sollte auch deutlich unter einer Sekunde bei einstelligen Millionen Datensätzen bleiben, auch wenn man keine großen Optimierungen vornimmt und Designfehler verhindert.

Das erscheint mir eher wie ein Wunschtraum. Kannst du das irgendwie begründen/nachweisen? Setup, Insert Script/Procedure etc.

Denke nicht, dass sowas auf Real World Scenarios zutrifft, geschweige denn auf Fiktive.

Ich denke er meinst, daß der Insert eines einzigen Records diese Zeit beansprucht, was derzeit auch bei mir funktioniert.

01.08.2008 - 17:28 Uhr

Hallo Sera,

Diesen Zusammenhang verstehe ich nicht. Warum ist die Spaltenanzahl wichtiger?
Dass eine fixe Vorgabe auch konstante Werte verursacht ist klar. Was die Frage ist: "kann man die Spaltenzahl verringern"? Denn wenn ja, dann wäre das ein Performancegewinn.

Tabellen schlank zu halten wird ein Problem, denn spätestens mit etlichen gejointen Tabellen wird das Auslesen schwerlastig (DB Design)
Das ist aber ein grundlegendes Problem, was z.B. auch Datenredundanz begründet / verwirft. Eien auf Einfügen getrimmte Tabelle wird immer langsamer zu lesen sein, als eine auf Lesen getrimmte und vice versa.

Entweder man entscheidet sich für eine Variante von beiden, oder man wählt einen Mittelweg auf Kosten der Leistung beider Operationen, das ist aber reine Design- und vor allem Anforderungsentscheidung.

Ein schnelles Lesen UND ein schnelles Einfügen bei diesen Datenmengen wird es nicht geben. (Wobei die Frage ist, was ist denn überhaupt schnell?) Ein SQL Server 2005 sollte auch deutlich unter einer Sekunde bei einstelligen Millionen Datensätzen bleiben, auch wenn man keine großen Optimierungen vornimmt und Designfehler verhindert.

Grüße
Norman-Timo

Definiton Schnelligkeit: Es soll schnell für den User sein, wenn er einen Eintrag durchführt und auf das Ergebnis wartet.

01.08.2008 - 17:21 Uhr

Was ist das für ein Server (CPU, Ram, Festplatte, Raid), wie ist er Konfiguriert (Ram-Nutzung-Gesamt, Ram-Netzung pro Select) usw?

Um wieviel Millionen Einträge handelt es sich, wie lang wird dafür gebraucht?

Wie sieht die Tabelle überhaupt aus? (Tabellendefinition)

CPU Quadcore 4x2,4
RAM 8 GB (wobei die RAM keine Rolle spielen, da Data Warehouse - denormalisert)
HD 2x 1 TB

Die Tabellen haben maximal 50 Spalten (nur wenige).

Einträge auf 2 Jahre - über 1 Mrd (6 Tabellen, Rest sind Fact Tables)

01.08.2008 - 14:51 Uhr

Danke für die Antworten.

@kleines_e

Um das Hinzufügen (und vor allem das Löschen) performant zu gestalten, ist es wichtig, das die Tabelle an sich schlank ist. Es zählt nicht die Anzahl der Datensätze sondern die Breite (Anzahl der Spalten). Was auch noch ein großer Faktor ist, sind Foreignd Keys sowie jede Art von Index. Halte diese auf ein minmum begrenzt

Diesen Zusammenhang verstehe ich nicht. Warum ist die Spaltenanzahl wichtiger? Die Tabelle hat eine bestimmte Breite. Nach dieser Logik müsste die Performance konstant bleiben, wenn wir keinen Index verwenden.

Tabellen schlank zu halten wird ein Problem, denn spätestens mit etlichen gejointen Tabellen wird das Auslesen schwerlastig (DB Design)

@GMLOD

Ist bereits implementiert. Trotzdem happert es schon bei ein paar Millionen Einträgen.

01.08.2008 - 14:09 Uhr

verwendetes Datenbanksystem: <SQL Server 2005>

Gibt es Möglichkeiten, das Inserten von Daten in DB zu steigern bzw. mit steigender DB nicht unbedingt linear Performanceverluste hinnehmen zu müssen?

z.B gab es einen Tipp, daß man immer explizit Transactions verwenden sollte, da implizit jedesmal eine Transaction aufgerufen wird und dies nicht besonders der Performance gut tut.

Ich bräuchte paar Tipps um INSERTS bis ca 1 Mrd Records stabil halten zu können.

Aktuelles Problem ist das Testen gegen das real existierende DB System mit noch wenig eingefügten Daten, deshalb wende ich mich an euch, die Erfahrung mit DBs haben, die selbst einen hohen Datendurchsatz haben.

10.07.2008 - 15:36 Uhr

Erstmals Danke für die Antwort, svenson.

Wie definierst du "konkreten Typ" und dessen Untauglichkeit für Plug-In Implementierung?

09.07.2008 - 13:34 Uhr

Zwecks Erweiterbarkeit sind AddIn Schnittstellen für die derzeit geplante Software (Host) im Gespräch. Da inkrementell entwickelt wird, gibt es verschiedene Meinungen für das frühzeitige Einfliessen der AddIn Struktur in das Grobkonzept.

Mittlerweile bin ich paar Tutorials durchgegangen und bin selbst der Meinung, daß sich AddIns nachträglich implementieren lassen (Interfaces only). Der Gegenpart ist eher der Meinung, daß im Falle eines nachträglichen Implementierens, das komplette Schnittstellenkonzept neu konzipiert und programmiert werden muss.

Hat jemand Erfahrung mit AddIn bzw Plug-In Programmierung und könnte bestätigen, daß diese nicht von der SW Architektur abhängig sind? Natürlich auch wenn ich falsch liegen sollte.

09.05.2008 - 12:55 Uhr

Router blockiert als Hardware auf beiden Wegen, die Win FWs stören nicht durch aufwändige Überprüfungen. Also wirst du nie diese Erfahrung mit diesem störenden Einfrieren gehabt haben. Zumindest wissen wir jetzt woran es liegt und wie man es lösen kann.

09.05.2008 - 03:29 Uhr

Ich habe das Verhalten mit einer anderen FW (Comodo) überprüft. Hier funktioniert es einwandfrei. Zonealarm überprüft anscheinend diesen Hosting Process seperat, was Zeit kostet.

@Khalid @Xqgene

Welche FW benutzt ihr? Möchte auch diese testen.

08.05.2008 - 17:05 Uhr

@Khalid

Ich nehme an, daß du diesen Inetzugriff zulässt, womit du auch dieses Verhalten nicht nachvollziehen kannst bzw. nicht bemerkst. Werde wohl die FW wechseln müssen, da die IP immer eine andere ist und jedesmal sich die FW darauf einstellen muss. Edition: VS08 TS, VS 2005 Pro

08.05.2008 - 15:55 Uhr

@Khalid

Ja, in der Tat. Werde es bei Bedarf einschalten müssen.

@JunkyXL

Keine Ahnung wie groß dein Proj ist. Probier es einfach mit irgendeinem Projekt, starte es und stoppe es letztendlich mit dem "Beenden" Button der VS IDE während der Laufzeit. Für eine kurze Zeit friert der Editor ein, du kannst den Cursor in den Editbereich nicht setzen bzw. nicht sofort editieren. Habe es auch mittlerweile bestätigt bekommen, daß der Hosting Proc. erst sich durch den Debugmodus aufbauen muss (die FW Abfrage bleibt trotzdem).

08.05.2008 - 13:09 Uhr

So zur aktuellen Lage:

Unter den Projekteigenschaften/Debuggen habe ich den Hosting Prozess disabled und nun ist das Problem gelöst. Ich hoffe diese nun abgeschaltete Option ist nicht nachhaltig von Nachteil.

08.05.2008 - 12:51 Uhr

lol, letzte IP war vom Server mycsharp3.de

Also es scheint nichts wirklich gefährliches zu sein...

08.05.2008 - 12:28 Uhr

Junky, starte ein Projekt im Debugmodus und betätige den Stop Button in VS. Einmal mit FW und einmal ohne (steck den Netzstecker aus). Schon ein Unterschied, nicht wahr? Auf der sicheren Seite aber so langsam.

08.05.2008 - 12:11 Uhr

Wenn jemand hier Zonealarm verwendet hat er vielleicht diese Erfahrung schon mal gemacht. Mögen andere FW dieses Problem anders handhaben, jedenfalls kann ich bestätigen, daß die Performance besonders bei Abbruch des Debugmodus total einbricht und die Projektmappe einfriert und ohne FW unmittelbar sofort ansprechbar ist.

08.05.2008 - 12:07 Uhr

Nein ist nicht befallen. Habe umsonst Win XP neu aufgesetzt und unmittelbar danach VS.

08.05.2008 - 12:02 Uhr

Habe auch dieses Problem inklusive Debugmodus. Nach Abschalten der Firewall habe ich mindestens 1000% Performancegewinn.

VS 2008, 2005 - Performance & Firewall