[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 22 Feb, 2013, at 11:16 am, Neil Winchurst wrote:
On 22/02/13 09:55, Simon Waters wrote:Sqlite is designed to embed in other programs. It is a file based system, with no database server. These kinds of database are okay for single user programs, but as a firm believer in feature creep I'd use Postgres for most programs requiring a sql database back end unless the requirements make it obvious I need something else.Why is it unusual? I had better explain. My last job before I retired was as a self-employed creator of small databases for local small businesses. I used a Windows program called Borland Paradox. This was what is known as a monolithic type, that is all included. It was of the same style as MS Access but in my opinion far superior.I assume the rampant database bloat in Firefox is more to do with how they use Sqlite than Sqlite itself.Not saying you are wrong to want a front end but seems unusual thing to ask.It included everything in one program that is tables, forms, queries, reports and, most important of all, its own built in script language called PAL (Paradox Application Language).All my work creating these databases was via the GUI in the program. Everything was done this way, there was no need to use a terminal screen at all.Likewise my clients were provided with a GUI program to use. If I had told them that they would have to learn to use a DOS type set up to use it, well they would still be laughing!My biggest problem with Linux is that there is no equivalent program available. Yes, I have tried Kexi and OO Base. They are trying but not there yet. Their biggest failing is that there is no simple way to use calculated fields. This is absolutely necessary in almost all databases and was included in Paradox (and Access) years ago. Databases are always the poor relation, the last to be worked on.So, why do I want a front end for sqlite? Because that is the way I like to work with databases. To me the idea of using a terminal screen to set up and use a database is just plain stupid.
I think you've got the wrong end of the stick here. Simon is recommending client-server and a DB "Management System" (DBMS) over stand-alone/embedded and file-based; *not* CLI over GUI.
Calculated fields are only a feature in standalone systems. In SQL- based systems they are implemented using the SQL query language, offering a great deal more power, flexibility, dynamism and customization. To get the equivalent (actually much more powerful) of a calculated field most modern SQL DBMSes offer what are called "views" -- essentially tables that are the output of queries on one or more underlying tables (and/or views). Calculated fields are actually a Bad Thing in large-scale database design in that they break what is called "normalization", a series of steps and tests for making sure you duplicate (ideally) nothing.
Conceptually, you need to be separating two areas of design that are unified (to some advantage, but with trade-offs) in Paradox etc: schema design (tables, indexes, etc) and form/application design (quite a different topic, with very different priorities).
I've never coded to PG but I know MySQL now offers views, and I'm sure I'd have seen something to the effect that PG was behind if it didn't, so I assume PG also offers them.
https://en.wikipedia.org/wiki/Database_normalization -- Phil Hudson http://hudson-it.no-ip.biz @UWascalWabbit PGP/GnuPG ID: 0x887DCA63 -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq