I know that in this use case UPDATE is lither than DELETE, but if I make a DELETE at 4am I can have the DB locked for a lot of time at 4am: I'm only shift the problem. It's not a problem of interface efficiency for user experience: the goal is to make the system always reactive without slow down all the other DB operation.
Il 11/10/2010 11.46, Simon Slavin ha scritto: > On 11 Oct 2010, at 10:26am, Michele Pradella wrote: > >> Soft delete could increase the SELECT speed because you have to check >> always for the "deleted" column. >> Moreover the DB will grow up without limit if no one physically delete >> the records: anyway UPDATE of a lot of records could be expensive too. >> I think the only way is to DELETE more frequently less records. > I recommend that you try it. At least in the command-line application if not > in your own code. Deleting a record is very expensive in terms of time and > resources. Changing a field from a 1 to a 0 is far cheaper and faster, even > if it's in an index or two. > > You can have a regular task that runs at 4am that deletes all the records > with a 0 in. That bit is easy. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- Selea s.r.l. Michele Pradella R&D SELEA s.r.l. Via Aldo Moro 69 Italy - 46019 Cicognara (MN) Tel +39 0375 889091 Fax +39 0375 889080 *michele.prade...@selea.com* <mailto:michele.prade...@selea.com> *http://www.selea.com* _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
