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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor