[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Neil Winchurst wrote: > When I refer to an all-in-one database I mean what I believe is > officially called a 'monolithic' database. Probably the simplest solution for your assumptions is LAMP. It provides the same MVC that you describe. The model is the detail of the database tables, indices and such. This can (and should) be hidden from the ordinary users by creating the view. The controller is then adapting the view using the model - showing only the data that the view uses. > That is, the one program > includes the database engine, the gui, the search, the query, the print > a report facility, a programming language, everything. This means that > there is no need to have any other program on your computer, everything > is included in the one program. You install and away you go. Which is, actually, a Bad Thing. The base software should already be installed and regularly updated without your intervention. It must, naturally, be free in cost and modification. Then all you need to provide is a simple package that holds: 1. The .sql scripts that create the database tables. 2. The scripts (PHP, Perl, etc.) that populate those tables. (These two provide the model.) 3. The HTML/PHP/Perl view interface that limits the number and style of the fields that are offered to the user. 4. The PHP/Perl scripts that control that view, populate it with data from the model and ensure data integrity using restrictions, validity checks, that sort of thing. (see isbnsearch) http://isbnsearch.sourceforge.net/ With that package, you then depend on firefox or a similar www-browser and the rest of LAMP and ask someone to sponsor the upload into your favourite distribution. Job Done. (OK, it's not always that easy if, like isbnsearch, you end up depending on some god-awful toolkit from the dark ages before TCP/IP but that's a cross I have to bear...) When you get to the client, ask them to gain root access and ask them to run: # apt-get install packagename Some sensible configuration then occurs and the user loads their favourite browser at, say, http://some.local.virtual.host You don't have to do all that yourself either, you can simply write a site in Maypole (or something similar). With some experience of Maypole (Aaron will confirm this) you can install and set up Maypole on-site. Blogs are also MVC packages. Wikis too. Every ecommerce site uses at least one MVC system. Any application that handles user data would also use at least one MVC. Basically, anything that does not expect the user to directly edit the underlying dataset. Even vi has an MVC of sorts because it can add syntax highlighting which is a view because it does not exist in the underlying data (the ASCII). vi also has a controller in the shape of autoindent etc. Don't fixate on the Paradox/Access MVC. MVC is absolutely everywhere - and note that any MVC system can include multiple models, almost by definition will include multiple views and often includes multiple controllers. Even a very simple MVC with one model and one controller usually has a couple of dozen views. Paradox/Access were limited to one model (certainly the last time I used them) and also one controller. That's pretty bad, all things considered. (The sad thing is that they got away with charging real money for that crap - I know, I paid it!) (Note: A single model includes multiple linked tables, the model is the schema - the plan - not the number of tables.) > The two Windows examples that I used were Paradox and Access. Once > installed everything is there. Here in Linux, as a simple example, to > use a gui with mysql I have to install a second program, in my case > Knoda. I see that there are other frontend offerings around too. The easiest GUI of them all is HTML, if only because it is so prevalent. Your all-in-one solution is actually LAMP: GNU/Linux, Apache, MySQL and PHP/Perl, preferably pre-installed. > The databases I wrote consisted of several linked tables and some forms > to show the records one by one. The forms could, if necessary, show > fields from two or more of the tables. PHP, Perl and thereby Maypole can cope with one HTML <form> that posts data to dozens of tables and produce a results page in HTML that includes end-view calculations on that data like totals, averages, graphing, even stats that are simply not present in the actual model. The user has no need to know about any of this. PHP and Perl have quite extensive report and graphing support, you'll find it hard to conceive of an output that cannot be represented in some combination of HTML and dynamically generated images. Despite attempts to emulate 3D, computer output is still inherently 2D. Even a "3D image" is just an optical illusion when made using a computer. > The users worked with the forms > and never saw the tables. (There was more to it then that of course > including reports and queries as required.) Precisely, this is MVC programming. Model, View Controller. You created the model in Paradox (as I used to do) but now you need to create that in SQL. You created the (awful) Paradox forms that have *none* of the power of a PHP or Perl method to create the view. You then create HTML <form>s that control that view. >> The idea that there is a reference code which returns one record from >> that database doesn't really fit. >> >> A code such as 2000 given to a specific program which operates on that >> database will return a view of the entire record relating to a specific >> person, but this is pages long, categorised and requiring navigation to >> make sense of. Not true. You've missed the role of the view. The underlying SQL query will return the entire record, but the VIEW determines how much of that record is displayed, how that record is combined with data from multiple other tables and multiple internal queries. e.g. when the user enters a term, the view can actually fire off multiple SQL queries, process the results and output a single view the incorporates only the data that the VIEW can support, irrespective of whether that data exists in multiple tables in the model or has been generated on-the-fly. >> > But the search facility I am talking about does not call up tables, it > calls up a form which includes only those fields that I, as developer, > choose to include, as required by the client. Yes, you as developer decide on the model, the view and the controller. The view both combines data from different tables and screens out fields that the user does not need to see. It also calculates new data from the model to create content that doesn't even exist in the model, like totals etc.. > >> One specific table of that database is restricted to one line (synonym: >> record) per person and thus searching that table for that person's ID or >> a unique foreign key we hold will bring up one record.. Only in the model. The VIEW can be whatever you need. > One record would include all details about the animal, taken from > several linked tables. If one of the workers wanted to see information > about Tiddles the cat, for example, she could call up a search window > and type the name in a press enter. Up on screen would appear a form > showing all the current information about Tiddles taken from all the > relevant tables. No problem, define the view to do that. Define the controller to update the view within those criteria. You seem to have missed the fact that processing does not stop at the model. As developer, you create a second processing level in the view. The fact that this happens outside the programme that runs the actual model is irrelevant. What matters is that the user never sees the programme running the model. The user only needs to see the view and interact with the controller. > This is what I mean by a search, and the facility was used by all my > clients on every database I have ever created. I just don't see how > they could have used the database without it. That's why it has existed in GNU/Linux since the very first conception of LAMP. Every website running LAMP implements a model / view / controller process. You leave the database engine to deal with the intricacies of the model. You create a nice, intuitive, HTML view that screens out the internal data and combines the data from disparate tables into a logical whole and then you create a PHP/Perl controller that updates the view with data from the model upon user intervention. Or you simplify the whole thing and use an existing solution like Maypole. :-) The DCGLUG website itself is a MVC environment. I use MySQL for the model (only 6 tables, but hey, it's not a complex site), PHP and HTML combine to create the views (and at last count there are 50 or more, some only slightly different one from another) and PHP and Perl combine to create two distinct controllers: the wiki and the membership. Don't tell me you have to interact with the raw SQL model to enter data into the wiki - you interact with a view created by the wiki controller. (Note: the wiki controller is not my own work. As you should expect from the above, I use an external package to provide the wiki and only tweak the controller if absolutely necessary. The views are also tweaked.) The controller is sufficient that even as webmaster, I have never had to actually do anything with the raw SQL data except create backups. Some controllers will even do that for you. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: OpenPGP digital signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html