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
