All relational database engines store configuration data within the users' database. Many of them just hide it behind varying layers of logically imposed complication. For example, you could simulate SQL Servers' obfuscation by simply changing the name of the primary database alias from "main" to "master" in the SQLite code, and then requiring that all "user" tables are stored in an attached database.
> -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Simon Slavin > Sent: Wednesday, 20 May, 2015 14:38 > To: sqlite-users at mailinglists.sqlite.org > Subject: Re: [sqlite] AUTOINC vs. UUIDs > > > On 20 May 2015, at 8:52pm, Kees Nuyt <k.nuyt at zonnet.nl> wrote: > > > The autoincrement clause causes an entry in the sqlite_sequence > > table. > > It's interesting that SQLite uses tables inside the user database for > private purposes like this. A certain wall is broken when the designers > choose this option. SQLite does it for sqlite_master, sqlite_sequence, > sqlite_stat*, and probably others I've forgotten. > > SQLite is handicapped by having no permanent data storage location. It > has nowhere to store configuration information apart from inside the > user's databases or as compilation settings. This is very unusual but, I > think, contributes a lot to how portable SQLite is: no need to understand > folder structure or safe places to keep configuration information; > increased startup-speed; reduced code size, fewer file handles, slightly > reduced memory. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
