Reply to thread

Message

<blockquote data-quote="kev160967" data-source="post: 136358" data-attributes="member: 26620">That's interesting - I must take a look at the TV engine's code at some pointHaving read up on SQLLite a bit more, it's not as cut and dried - it implements more language features than I anticipated initially. However there are a few SELECT/ACT/SELECT/ACT operations taking place in the C# at the moment, and I'd be inclined to implement them as stored procedures. Apart from simplifying the relevant code, we've also seen big performance improvements in our own apps by reducing the amount of round tripping to the database.Also, I've added an idAlbumArtist column to the song table. I obviously need to load Song objects with this data when they're fetched from the database. If you take a look in MusicDatabase.cs you'll see there are dozens of effectively identical (in terms of what they retrieve) select statements pulling back song data for different purposes, some using explicit joins, some joining via the where clause. With the current code I'd have to alter every one of these (instead I've rewritten the code so all the methods call a single method, just specifying a different where clase). If I was writing against SQL Server I could write a view for this, and then always select against the view, reducing the number of places I'd need to change my select clause to 1.Anyway, that's probably enough waffling about it,Kev</blockquote>

[QUOTE="kev160967, post: 136358, member: 26620"] That's interesting - I must take a look at the TV engine's code at some point Having read up on SQLLite a bit more, it's not as cut and dried - it implements more language features than I anticipated initially. However there are a few SELECT/ACT/SELECT/ACT operations taking place in the C# at the moment, and I'd be inclined to implement them as stored procedures. Apart from simplifying the relevant code, we've also seen big performance improvements in our own apps by reducing the amount of round tripping to the database. Also, I've added an idAlbumArtist column to the song table. I obviously need to load Song objects with this data when they're fetched from the database. If you take a look in MusicDatabase.cs you'll see there are dozens of effectively identical (in terms of what they retrieve) select statements pulling back song data for different purposes, some using explicit joins, some joining via the where clause. With the current code I'd have to alter every one of these (instead I've rewritten the code so all the methods call a single method, just specifying a different where clase). If I was writing against SQL Server I could write a view for this, and then always select against the view, reducing the number of places I'd need to change my select clause to 1. Anyway, that's probably enough waffling about it, Kev [/QUOTE]

Verification