[Tutor] Long post: Request comments on starting code and test code on chess rating project.

[Alan Gauld]

On 16/08/17 04:06, boB Stepp wrote:

>> I agree with Neil, this is exactly what SQL is good for and
>> would make this part of the project much easier and would have
>> the added benefit of introducing you to one of the trickiest,
>> but most common, bits of OOP - object persistence...
> 
> Would you expand on this in SQLite terms?

I'm not sure which bit you want expanded so I'll do both :-)

The reporting side is easily within SQLite's capabilities
once you have the table structures defined. And SQLite's
big benefit for this kind of project is that there is
no server involved just a single data file, so easy
to maintain. You can even use the in-memory mode if you
just want the SQL aspects and are happy to persist
your objects in text files(JSON maybe?) Simply load
the JSON data into SQLite in-memory tables to perform
the queries.

The persistence issue really has nothing to do with
SQLite per se. To persist (ie store) your objects
between program runs requires that you save them
to disk somehow. Simple classes can be saved in
simple text files. but as classes contain other
classes/objects that gets complex. The next step
is a formatted storage mechanism like XML or JSON
which can handle nested objects. The other issue
in persistence is when to save the objects? Do
you just load everything into memory at startup and
then write it all back at shutdown? Or do you
incrementally save all changes as they happen?
In a dynamic, garbage collecting language like
Python incremental saves are safer in case an
object gets deleted accidentally, before it is saved.

But sooner or later you will need to move to a database
and that brings the issues of translating a class
into tables - especially if inheritance is involved.
Do you have a table per class with superclass links?
Or do you duplicate the  superclass attributes in
each child table? There are no right answers and
figuring out the most effective mapping is one of
the big challenges in real world OOP projects.

Another option is to adopt an Object Relational
Mapper (ORM) which will create and manage the SQL
aspects for you - but in the process make reporting
more difficult.

And lastly you could use a NoSQL database like Mongo
which can more easily persist complex objects and has
a reasonable reporting language (especially if you
use Mongoose). But this is likely a much bigger learning
curve, especially if its the first time you've used
it.

For your project I suspect a JSON solution would
be fine for persistence but no help for reporting.
SQLite, especially if you don't have lots of
complex classes, gives both for low cost (both
resources and learning) assuming you know basic
SQL to start with.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos