the idea its that many tools generated (due portability and compability) sql script with a optional keyword COMMENT on each column definition..
this its xxtremely usefull for selft container documentation for many console users and rapid development so manual comment using C-like cannot do that, if i have a large set of DB's with minimal of 20 tables, its widelly tedious manage comments in that way that some here sugest me.. and later joint the db files for work? .. and stop of recomend me stupid guindows tools like sqlitespeed, does not sqlite are Public Domain thanks god and aliens, but i hate all the protected breaking-portability like all the guindows progs, the main reason that's why we have problems porting apps Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-03-15 11:05 GMT-04:00 Richard Hipp <d...@sqlite.org>: > On 3/15/17, Simon Slavin <slav...@bigfraud.org> wrote: > > > > It’s common to see a four column table, with the columns being > > > > entityType > > theTable > > theName > > theComment > > > > This approach has the advantage of being portable across *all* SQL > database engines, whereas the COMMENT ON command is (as far as I could > discern from Google) only available on Oracle and PostgreSQL. This > approach also makes the comments easy to introspect from applications, > and update using general-purpose query tools. > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
