ok, so say i have this one application that has a need to access many different tables. Since i have the database itself on a server, and my application is sitting on a workstation (and for the sake of multi-tiering), the data manager/retrieval classes are sitting on yet another server.
Lets say i have 100 tables that i wish to query (for whatever reason) within that one application. Now, of course i could write a separate data manager/retrieval class for each and every table (which perform the insert, select, update, delete functions), but thats just silly to write 100+ data manager/retrieval classes.
ok so now ive decided i want just ONE (or a few - handful) of these data manager/retrieval classes to handle all 100+ tables. how does one go about doing this? since every table has different field names, different functions that i would want to perform etc.
Full Version: Data Manager/Retrieval classes
If you are good at SQL, adn depending upon what database you are using, (I preferr Oracle), you can use sql to reveal the column names and datatypes dynamically.
Then you could build your query according to your business logic.... whatever that may be... I don't know so I can't guess.
dude, I would write a class for each business case. Not one monster, mother of all SQL builders. I really don't think what you propose is a good idea.
Make a separate class to satisfy EACH individual Business task. You could build many interfaces and then have your classes inherit from them what they need to do the task at hand.
I am also assuming that the 100 tables have relationships so there are Join rules (that is JOIN... not JOINT.. lol) involved as well.. how would your one size fits all approach work?
I don't want to bash your idea, I just want you to think about it... don't let technology dictate what must be done... BUSINESS rules and logic MUST drive the development phase..... or you will be overtime and OVER-BUDGET...
KISS... Keep It Simple Stupid... as it was taught to me, I know pass it on to you.... really do keep it simple.
Then you could build your query according to your business logic.... whatever that may be... I don't know so I can't guess.
dude, I would write a class for each business case. Not one monster, mother of all SQL builders. I really don't think what you propose is a good idea.
Make a separate class to satisfy EACH individual Business task. You could build many interfaces and then have your classes inherit from them what they need to do the task at hand.
I am also assuming that the 100 tables have relationships so there are Join rules (that is JOIN... not JOINT.. lol) involved as well.. how would your one size fits all approach work?
I don't want to bash your idea, I just want you to think about it... don't let technology dictate what must be done... BUSINESS rules and logic MUST drive the development phase..... or you will be overtime and OVER-BUDGET...
KISS... Keep It Simple Stupid... as it was taught to me, I know pass it on to you.... really do keep it simple.
and in the end, you ARE going to have to develop the SQL for each and every scenario because you will have NO WAY of testing to see if your monster is doing its job....
I have been developing and designing databases and applications for 13 years my friend.... I went down that track you are facing now.... don't waste your time, effort, or your customer's money... or you might find that you program yourself out of a job.
I have been developing and designing databases and applications for 13 years my friend.... I went down that track you are facing now.... don't waste your time, effort, or your customer's money... or you might find that you program yourself out of a job.
Depending on the language you are using to program the application itself you may wish to create a base class that provides the basic data manipulation functions and then derive from that base class for any specialized classes you need that require specialized functionality in them. If you're using VS.NET, you can use any of the .NET compliant languages to do this, since inheritance is part of the spec for being .NET compliant.
i was thinking more of something like what ldonyo said... i can do something generic for the more basic SQL statements, but obviously different forms within the application will have differring needs so I will have to cater for that in a more customised way..
its just that i actually have 2 classes for EACH table right now, one that just "manages" and the other one that actually does the interfacing with the database. so u can think of it as 4-tier (i think thats what they call it - blame my lecturer if im wrong :P )
im thinking about it first, perhaps i can have 1 manager per table, but have a more generic data retrieval class (the class that actually interfaces with the database doing the actual SELECT, INSERT, UPDATE queries).
im still learning as i go so dont hurt me manny
its just that i actually have 2 classes for EACH table right now, one that just "manages" and the other one that actually does the interfacing with the database. so u can think of it as 4-tier (i think thats what they call it - blame my lecturer if im wrong :P )
im thinking about it first, perhaps i can have 1 manager per table, but have a more generic data retrieval class (the class that actually interfaces with the database doing the actual SELECT, INSERT, UPDATE queries).
im still learning as i go so dont hurt me manny
what about the joins? those are very specific... AND SQL should be highly optimized (yes, that's right) for the task at hand.
If you don't know the rules of optimization, your app could take forever if there are a lot of joins as is the case where you are dealing with a highly normalized data structure in true 3rd normal form.
A couple generic INTERFACES... not CLASSES. there is a HUGE difference. The Interface contains all the logic with no data references as the class does.
Classes can inherit from Interfaces. That is the approach.
If you don't know the rules of optimization, your app could take forever if there are a lot of joins as is the case where you are dealing with a highly normalized data structure in true 3rd normal form.
A couple generic INTERFACES... not CLASSES. there is a HUGE difference. The Interface contains all the logic with no data references as the class does.
Classes can inherit from Interfaces. That is the approach.
lol sorry, i know i dont have my terms correct.... so i have generic interfaces that query the database itself, and i have 1 class for each table so that i can keep each class customised towards any specific need. :P
ill get this right someday...
ill get this right someday...
you are well on your way man... well on your way. don't give up... just trying to save you from some pit-falls I have been in
If you can put most of your SQL needs into Stored Procedures and call them from your application, instead of having to dynamically generate SQL statements from within your code, you should see a noticeable performance gain as well as making it far easier on yourself to debug your application.
yes lDonyo, but he may not be at that level yet. And then, he is more tightly coupled to a specific DB like Oracle or SQL Server. In those two cases, the Stored Procedures are VERY different syntactically.
Depending on the driver used, you can sometimes use it to create a server side cursor which is the same thing. Using ADO is a good way to go as well as MS Transaction manager to keep connection pools for efficient use of objects and db connection licenses.
Depending on the driver used, you can sometimes use it to create a server side cursor which is the same thing. Using ADO is a good way to go as well as MS Transaction manager to keep connection pools for efficient use of objects and db connection licenses.
QUOTE
what about the joins? those are very specific... AND SQL should be highly optimized (yes, that's right) for the task at hand.
If you don't know the rules of optimization, your app could take forever if there are a lot of joins as is the case where you are dealing with a highly normalized data structure in true 3rd normal form.
A couple generic INTERFACES... not CLASSES. there is a HUGE difference. The Interface contains all the logic with no data references as the class does.
Classes can inherit from Interfaces. That is the approach.
If you don't know the rules of optimization, your app could take forever if there are a lot of joins as is the case where you are dealing with a highly normalized data structure in true 3rd normal form.
A couple generic INTERFACES... not CLASSES. there is a HUGE difference. The Interface contains all the logic with no data references as the class does.
Classes can inherit from Interfaces. That is the approach.
I believe Classes implement Interfaces, not inherit them. Syntactically it looks very similar, but the compiler knows the difference. :wink:
Classes CAN inherit from Interfaces in C# which I am studying to certify in soon 
in fact if you implement a data adaptor class using ADO and C++, you are in fact inheriting from the IDbDataAdapter interface.
http://msdn.microsoft.com/library/default....rclasstopic.asp
"An application does not create an instance of the IDbDataAdapter interface directly, but creates an instance of a class that inherits IDbDataAdapter and DbDataAdapter."
In effect, I guess you're right anyway.... but I have to speak their language to pass the tests. If they say a class inherits from an interface, that is what I have to re-gurgitate... but I agree... the whole point of exposing ONLY the interface to a base class is so that other classes can implement the functionality.
in fact if you implement a data adaptor class using ADO and C++, you are in fact inheriting from the IDbDataAdapter interface.
http://msdn.microsoft.com/library/default....rclasstopic.asp
"An application does not create an instance of the IDbDataAdapter interface directly, but creates an instance of a class that inherits IDbDataAdapter and DbDataAdapter."
In effect, I guess you're right anyway.... but I have to speak their language to pass the tests. If they say a class inherits from an interface, that is what I have to re-gurgitate...
but I agree... the whole point of exposing ONLY the interface to a base class is so that other classes can implement the functionality.
It does sound like a to-may-toes vs. to-mah-toes kind of thing, doesn't it? 
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.