Hi Kevin, My Supervisor just wanted to know so that I could use it as a reason in my justification in choosing a method, it wasn't going to be used as the main reason, just 1 in a list of reasons as I couldn't base my decision solely on "I know OO, so I'll choose that".
Your suggestions are really good and sound a lot more interesting that my project, which is to build a GUI to SQLite for ease of use for new or novice users, but sadly the project proposal has already been submitted before Christmas and it is too late to change as the project is due to be finished on the 2nd May, which I doubt I will finish it by as I am still on the analysis phase of my project, I can get a 2-3 weeks max extension due to ill health but still don't think this will be enough time. Many thanks for your comments. Aaron. On 13/04/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I have been doing various experiments in applying OO to databases and > might > have a few suggestions to make. > I would be interested to provoke debate as to how to apply OOP to a > database > like SQLite; > > I haven't quite understood why your tutor wants to know if the database is > structured using OO: this would affect how you program the server side of > the database (not very relevant to SQLite), but the Client side (or user > interface) can be created using whatever principles you wish; > > Oracle has provision for OO, as I understand with a preference for Java > oriented programming, though the object oriented structure works also in > PL/SQL (PL/SQL and Java are contentious concerning the direction that > Oracle > will be taking for its programming language: some think that ultimately > Java > will take over: there is a certain logic in pushing towards using the same > language for the frontend as you use for the backend); > I have followed SQLite's evolution with interest (as a Delphi programmer > now > moving towards C# and possibly Java), though as I understand it, SQLite > isn't (yet?) structured towards using objects as part of its internal > programming language; > Oracle has the 'package' which internally groups functions and procedures > together with variable declarations: a good way of applying OOP since it > favours modularity; Oracle has also the Object Type, the object Table and > the Object View (the Object Type is analogous to the Class in C++ or Java) > and all the usual elements of OOP (Inheritance, Encapsulation, > Polymorphism > etc.); > I presume that to apply a similar structure to SQLite, it would require > the > development of an outer object-oriented 'shell' which would have the non > object-oriented SQlite 'motor' at its core: the database 'objects' would > have to persist in the database in some way (presumably implying that the > database contains a structure which would create and maintain them); > Normally Objects on the database side would be part of a database server > and > would imply the use of a complex language interpreter on the server side > (SQLite is not really a server in this sense and has only a simple > internal > language: Lite after all!!); > > In Delphi, I made a multi tier program, which was object-oriented, using > COM > and dbexpress to connect to SQLite : > when a module was called on the client, instructions were sent to the > client > server which then created its data objects dynamically by means of COM > function calls, opened a session with the database etc > Another set of instructions from the client executed functions on the > client > server which sent the corresponding SQL instructions to the database; > On the client I created instanced 'Table_Objects', one for each table I > wanted to use: these had various methods that I inherited from an ancestor > TableObjectType (insert, update, delete etc): just calling these functions > with the field values caused the SQL script to be parsed and executed on > the > server; any 'stored procedure' type functionality would be done by > creating > specific OO structures (in this case using Delphi) on the server side; > (Obviously the client, server and SQLite modules can be on separate > computers, though the concept is really for multiple clients) > > As far as your project is concerned, you could propose writing an object > oriented module that could work as the 'client server' part: this would > dialog with the SQLite database and with all instances of the clients by > opening an 'SQLite session' for each; a second 'client module' could > manage > 'table objects' which encapsulate the stuctures on the database and which > retrieve user data as required and which update the database by dialoguing > with the client server; (the end result would be a bit like one of the > heavyweight RDBMS's like Oracle, except that it would be lightweight and > it > would be exclusively object oriented in that there is no need for a second > 'server side language' like PL/SQL or whatever, since this functionality > is > 'compiled in' on the server and on the client but not required in the > database 'motor' itself); > As I understand, you are working in C#: I have been working on a project > in > C# for generating code from the database table structure which will > encapsulate table functions in a TableObject (as described above in Delphi > except that I wrote the code by hand, whereas the C# program generates > it): > the generated code that it exports creates a descendant object in C# (or > Delphi or Java) which in turn can execute SQL scripts in a single or > multitier situation depending on where you decide to place the objects and > how you connect to the database (if you go for single tier you could > compile > the 'client' and 'client server' functionality into the same executable, > though you would maintain clarity by keeping their modularity distinct and > separate); > > Hope my comments are useful, and I would appreciate any feedback, > > regards, > > Kevin O'Neill > >
