Re: [suse-linux-uk-schools] MIS, databases
However, I wouldn't exclude the possibility of writing special clients if functionality required it (and I'd write them in Tcl/Tk, for portability).
I would argue strongly that special clients should not be required or provided. Once you provide them, then there is a temptation to implement functionality in them that is not available in the web clients, and I believe that in this day and age there is very little that cannot be done with cleverly designed web pages and server side software. That said, I think this implementing such a system is an excellent idea. Does anyone on the list have a handle on the value for the average cost per school x total number of UK schools for current systems? Cheers -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org
However, I wouldn't exclude the possibility of writing special clients if functionality required it (and I'd write them in Tcl/Tk, for portability).
I would argue strongly that special clients should not be required or provided. Once you provide them, then there is a temptation to implement functionality in them that is not available in the web clients, and I believe that in this day and age there is very little that cannot be done with cleverly designed web pages and server side software.
I agree with both your arguments against special purpose clients: those are excellent reasons to try to avoid them. However, until we know the requirements we can't say there won't be some strong requirement that can't be implemented with a web browser, and if that were to happen, I'd want to solve the problem with Tcl/Tk (in preference to Java, by the way). I'd happily start working the details out based on an 'Any Browser' constraint (see www.anybrowser.org) for the user interface. Aiming everything at a browser might unnecessarily contrain user interfaces too: for example, we might more easily do a 'drag-n-drop' interface in Tk than as a web page, and (IMHO) Tcl/Tk is lighter weight than Java for this sort of thing. I can also do simpler editing interfaces with Tcl/Tk (no need to refresh a page when I edit or create an item), using the same HTTP transactions that a clunky web interface would use. Bob Gautier Ateb Limited
I have delevoped quite a few 'small' systems now using PostgreSQL and Perl CGi's and I have found the development cycle very fast compared to the more traditional methods (my main job is COBOL programming). However, I have, even on these small systens, found times when this interface too limiting. With the size of this proposed system I can see that at some point this will happen. I see this as one more reason for using PostgreSQL. As will as the native C libraries and the various perl modules (I prefer DBI) for accessing PostgreSQL, there are ODBC drivers for it. This opens it up then for practically any development environment, even using Access as the front end - although I found this far too much effort. Delphi apps work brillient with it. I use the built in Delphi database movetable to port data to/from PostgreSQL with ease. I find the �50,000 costs suggested in another branch of this thread to be a bit excessive. Surely there would be enough support for a normal open-source project. Once the data model has been agreed, and some basic goals specified, there should be no problem with dishing out code jobs the suitable volunteers. I would imagine there could be a working prototype will within the 7 months mentined. Gary On Sunday 29 April 2001 8:33 pm, Robert J Gautier wrote:
However, I wouldn't exclude the possibility of writing special clients if functionality required it (and I'd write them in Tcl/Tk, for portability).
I would argue strongly that special clients should not be required or provided. Once you provide them, then there is a temptation to implement functionality in them that is not available in the web clients, and I believe that in this day and age there is very little that cannot be done with cleverly designed web pages and server side software.
I agree with both your arguments against special purpose clients: those are excellent reasons to try to avoid them. However, until we know the requirements we can't say there won't be some strong requirement that can't be implemented with a web browser, and if that were to happen, I'd want to solve the problem with Tcl/Tk (in preference to Java, by the way).
I'd happily start working the details out based on an 'Any Browser' constraint (see www.anybrowser.org) for the user interface.
Aiming everything at a browser might unnecessarily contrain user interfaces too: for example, we might more easily do a 'drag-n-drop' interface in Tk than as a web page, and (IMHO) Tcl/Tk is lighter weight than Java for this sort of thing. I can also do simpler editing interfaces with Tcl/Tk (no need to refresh a page when I edit or create an item), using the same HTTP transactions that a clunky web interface would use.
Bob Gautier Ateb Limited
-- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000
On 30 Apr 2001, at 11:12, Gary Stainburn wrote:
I see this as one more reason for using PostgreSQL. snip...snip... Delphi apps work brillient with it. I use the built in Delphi database movetable to port data to/from PostgreSQL with ease.
Gary, Some questions if thats ok.... How were you connecting Delphi to PostgreSQL ? Using ODBC? Can you connect TStoredProc components to PostgreSQL procedures and invoke them from the client? Do you know of any components that can connect to PostgreSQL without having to distribute the BDE? I still use D3 c/s. I have seen references to Zeos Database Objects but cannot actually find any live sites for them. regards Richard richard@tortoise.demon.co.uk
hi interesting thread developing here, i've a meeting tommorrow to discuss an 'open source' SIMS alternative, including discussions on reverse engineering some of it. An early estimate from the developer is that about £50,000 of their time could provide a working basis for a project. Like many small companies, they'd need the money up front, too risky to create a product in the hope of uptake. Some facts:- - Capita state that SIMS has 90% of the schools market for admin software, and who says Micro$oft were anti-comptetive - DfEE policy is forcing everyone to move to EDI for school admin - the other competitors in the market (state schools at least) include Successmaker, about 3% of the market. - none run on Linux, all locked in to Access/SQL server, although you can view them as native DB's plenty of other people in the education market (Viglen, RM (?) and others) would like an alternative. Perhaps one of them can back the development. and my choice would be MySQL/Postgresql backend and PHP/perl for the interface. Malcolm On Sunday 29 April 2001 17:55, Phil Driscoll wrote:
However, I wouldn't exclude the possibility of writing special clients if functionality required it (and I'd write them in Tcl/Tk, for portability).
I would argue strongly that special clients should not be required or provided. Once you provide them, then there is a temptation to implement functionality in them that is not available in the web clients, and I believe that in this day and age there is very little that cannot be done with cleverly designed web pages and server side software.
That said, I think this implementing such a system is an excellent idea.
Does anyone on the list have a handle on the value for the average cost per school x total number of UK schools for current systems?
Cheers -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org
-- ------------------------------------ Malcolm Herbert Red Hat Europe t:+44 1483 734955 m:+44 7720 079845 ------------------------------------
hi
interesting thread developing here, i've a meeting tommorrow to discuss an 'open source' SIMS alternative, including discussions on reverse engineering some of it. An early estimate from the developer is that about £50,000 of
Which bits of it...
their time could provide a working basis for a project. Like many small companies, they'd need the money up front, too risky to create a product in the hope of uptake.
Some facts:- - Capita state that SIMS has 90% of the schools market for admin software, and who says Micro$oft were anti-comptetive
IIRC MS have recently put quite a bit of money into Capita. Probably explains the reason why they want to move things to Microsoft SQL. (Interestingly I now have a Windows 2000 server which can't be seen by Windows 95 on the network, but smbclient can see fine...)
- DfEE policy is forcing everyone to move to EDI for school admin
Dosn't help with a) LEA people ignoring their own policy on document formats (and emailing MS word documents with added virus.) b) propirtary EDI systems which can only run on single machines. c) EDI systems which are too complex for staff such as exams officers to understand...
- the other competitors in the market (state schools at least) include Successmaker, about 3% of the market. - none run on Linux, all locked in to Access/SQL server, although you can view them as native DB's
Or more to the point locked to Windows...
plenty of other people in the education market (Viglen, RM (?) and others) would like an alternative. Perhaps one of them can back the development.
Not to sure about RM, given my recent experience, through SWGfL... -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
Further comments! I was thinking in terms of the back-end database structure being public domain, with SQL scripts for the generation of tables, constraints and so on being open source.
I would argue strongly that special clients should not be required or provided. Once you provide them, then there is a temptation to implement functionality in them that is not available in the web clients, and I believe that in this day and age there is very little that cannot be done with cleverly designed web pages and server side software.
If the project was conducted in public, authors of the database structure would have no control over what clients others may or may not write.
I'll second the choice of PostgreSQL for the database engine,
I have come to depend heavily on stored procedures which as I understand it are supported by neither PostgreSQL or MySQL. There are things that such an application would have to do that would seem to me beyond the reach of a database without some programming capability. I could give examples if it would help. This is why I was considering Interbase. Also, as Interbase is available for both Linux and Windows, a project based on it may gain more momentum. Perhaps someone knowledgeable on PostgreSQL or MySQL could comment. regards Richard richard@tortoise.demon.co.uk
On Sat, 5 May 2001 richard@tortoise.demon.co.uk wrote:
I'll second the choice of PostgreSQL for the database engine, I have come to depend heavily on stored procedures which as I understand it are supported by neither PostgreSQL or MySQL. There are things that such an application would have to do that would seem to me beyond the reach of a database without some programming capability. I could give examples if it would help. This is why I was considering Interbase. Also, as Interbase is available for both Linux and Windows, a project based on it may gain more momentum. Perhaps someone knowledgeable on PostgreSQL or MySQL could comment.
PostgreSQL does have the functionality you are looking for. Try looking up triggers in the PostgreSQL manual. Michael
PostgreSQL does have the functionality you are looking for. Try looking up triggers in the PostgreSQL manual.
Michael Are not triggers procedures that execute in response to an operation on a table? http://www.ca.postgresql.org/devel- corner/docs/postgres/triggers.html I mean procedures that can be called from a client, or from within another procedure, which would include, but is not limited to a trigger. I also looked at http://www.ca.postgresql.org/devel- corner/docs/postgres/xplang.html but it looks a scary! regards Richard richard@tortoise.demon.co.uk
On Sat, 5 May 2001 richard@tortoise.demon.co.uk wrote:
PostgreSQL does have the functionality you are looking for. Try looking up triggers in the PostgreSQL manual. Are not triggers procedures that execute in response to an operation on a table? http://www.ca.postgresql.org/devel- corner/docs/postgres/triggers.html I mean procedures that can be called from a client, or from within another procedure, which would include, but is not limited to a trigger.
Yes - triggers are a mechanism for triggering calls to procedures whenever certain actions (e.g. SELECT, UPDATE, INSERT, DELETE) happen. You can use them to do things like consistency checks (trigger BEFORE an UPDATE or INSERT and flag an error if the check fails), creating audit trails (always add user names and timestamps to every record, or even create a separate transaction log if you want to), creating editable VIEWs, etc. Procedure creation and trigger creation is separate - you create the procedure first and then you can create a trigger that calls it if you want. You don't have to use triggers - they just seem to me to be the most obvious way to hook the procedures in, because you can then make almost everything invisible to the database client, giving you a 'clean' interface to the DB. Michael
participants (7)
-
Gary Stainburn
-
Malcolm Herbert
-
Mark Evans
-
Michael Brown
-
Phil Driscoll
-
richard@tortoise.demon.co.uk
-
Robert J Gautier