Large databases
-
I am currently (again) updating a database application that I wrote last summer. I need to add a new feature.... This brought one big question to me: Is there now way of making my database loading smarter??? Like loading it all once in one place and link all things to that one place?? Well, here it is the question: Anyone having any idea if it is possible to load the database once and use it anywhere in the application? This should reduce the amount of memory needed by the application to run. Since information like "members" and so on will only be in memory in one place instead of the six places at this very moment. (I ran out of virtual memory, and that's a bad thing :( ) Greetings.... :)
-
I am currently (again) updating a database application that I wrote last summer. I need to add a new feature.... This brought one big question to me: Is there now way of making my database loading smarter??? Like loading it all once in one place and link all things to that one place?? Well, here it is the question: Anyone having any idea if it is possible to load the database once and use it anywhere in the application? This should reduce the amount of memory needed by the application to run. Since information like "members" and so on will only be in memory in one place instead of the six places at this very moment. (I ran out of virtual memory, and that's a bad thing :( ) Greetings.... :)
The tradeoff really depends on what you're doing. If you're going to be touching all the data often, loading it all in can be good. If you only touch a fraction of the data, then loading it is probably bad. You may want to look at your database structure to see if you can make it more effective.
-
The tradeoff really depends on what you're doing. If you're going to be touching all the data often, loading it all in can be good. If you only touch a fraction of the data, then loading it is probably bad. You may want to look at your database structure to see if you can make it more effective.
The data in the database is used very often and is mostly combined in one view. My idea is to make a class the holds all the methods for editing and viewing the data in the database. Then I need to make one static instance in the main class of my program, so I can access it from all the other forms and classes. I use DataAdapters and DataSets to display all the data, I guess there's no other way than loading the whole table that's managed with the dataAdapter. Maybe someone does have another idea for loading the data? Greetings.... :)
-
The data in the database is used very often and is mostly combined in one view. My idea is to make a class the holds all the methods for editing and viewing the data in the database. Then I need to make one static instance in the main class of my program, so I can access it from all the other forms and classes. I use DataAdapters and DataSets to display all the data, I guess there's no other way than loading the whole table that's managed with the dataAdapter. Maybe someone does have another idea for loading the data? Greetings.... :)
I've used the approach that you're thinking of with some reasonable success (but remember that I'm a Microsoft PM, and therefore, by definition, never write any *real code). Having it central has made things quite a bit easier, and allowed me to centralize things like caching. My personal preference is not to use DataAdapters and DataSets when I take this approach, and write routines that look like: public List GetValues (string selectStatement) { OleDbCommand select = new OleDbCommand (selectStatement, connection); List list = new List (); OleDbDataReader reader = select.ExecuteReader (); while (reader.Read ()) { list.Add ((T)reader[0]); } return list; } This is a version using Whidbey generics, but you get the idea. For me, this is much simpler to code and understand than using the built-in data support in VS. Of course, I spent 3 years working for a database company (SQL is my friend...), so your mileage may vary.
-
I've used the approach that you're thinking of with some reasonable success (but remember that I'm a Microsoft PM, and therefore, by definition, never write any *real code). Having it central has made things quite a bit easier, and allowed me to centralize things like caching. My personal preference is not to use DataAdapters and DataSets when I take this approach, and write routines that look like: public List GetValues (string selectStatement) { OleDbCommand select = new OleDbCommand (selectStatement, connection); List list = new List (); OleDbDataReader reader = select.ExecuteReader (); while (reader.Read ()) { list.Add ((T)reader[0]); } return list; } This is a version using Whidbey generics, but you get the idea. For me, this is much simpler to code and understand than using the built-in data support in VS. Of course, I spent 3 years working for a database company (SQL is my friend...), so your mileage may vary.