On 4/6/10 18:50 , "BareFeet" <list....@tandb.com.au> wrote:
> I understand that in many cases, the SQLite database developed are > intrinsically tied to and designed for the application framework in which they > reside. However, even those SQLite database files can be opened and > manipulated by a SQLite GUI tool or the sqlite3 command line tool. In fact, > the developer of those probably highly specialized database files no doubt > created the databases using a GUI or command line tool. In theory it's possible. In practice, it's often of limited value. Often, much of the domain-specific behaviour is encoded in the real application rather than in the SQLite file. The app itself is often a lot more than a shallow GUI on top of a database. In fact, when wanting to transfer much of that domain-specific behaviour, I found that when it was possible, it was also cumbersome and error prone. For me SQLite is most of the time a high-level document file format. The fact that behind the curtain it's also a SQL database is nice but not essential. To be more specific, my applications usually use Core Data as the data persistence layer. My data models are designed using Xcode's graphical entity-relationship design tool which generates specific design documents ( xxx.xcdatamodel) and the corresponding SQLite databases automatically. Out of curiosity, I sometimes opened the resulting SQLite files with general-purpose SQLite tools, and this might occasionally be useful for debugging purposes, but certainly not for educational purposes. I suspect this would generally be the case, and the reason why no sharing of SQLite structure has emerged. For sharing purposes, the Xcode entity-relationship document (or some such) would be more interesting. Jean-Denis _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
