Danie,
> I like the scenario you are painting, there are still some concerns from
> my side though. I am worried about some of the actual SQL used in some
> of the php files. For those functions that do fail, I would like to
> introduce separate functions in ConfigDB.inc and ConfigDB_pg.inc just
> keeping it separate for now while I am testing.
>
You mean ConnectDB.inc? Yes I agree we should perhaps hold off publishing
any files or claims of Postgres compatibility until you are convinced it is
stable on Postgres.
> This might cause some discomfort for you, so I would like to run this
> past you first. What would happen is that in the PHP code where the SQL
> use to be, there would then be a function call which would exec the
> required functionality and return data as expected.
Could we consider making the SQL more generic in those areas where there is
a problem? If there is a KIS - Keep It Simple - solution then this would be
my preference.
How widespread are the problems?
>
> Once again I think this would leave the way open for other developers
> that might have an interest in other Databases like ( FireBird or Oracle
> for instance ). Also in the case of RDBMs additional Stored Procedures,
> Triggers and Views might be implemented on the DB side to help speed
> things up and these would be an-add on DB script loaded after the
> standard MySQL converted script has been loaded. Therefore 2 phase
> approach.
>
This would create one almighty include file for parsing on every script
would it not? If so it might actually slow things down!
I like the concept of keeping required triggers inside the application
wherever possible and being rigorous in maintaining db integrity with a few
extra sql calls. I am not convinced at the value of Stored procedures
either. In a client server application it is one thing where the network is
saturated, but this application is so lean it is hard to envisage this. I
would much rather modify every sql statement in the application to keep it
generic. Also, the network traffic for db calls is all between web-server
and sql-server in installations less than 100 seats this will most likely be
the same machine - the throughput of the network will not be a snag. In
terms of speed of processing of pre-compiled stored procedures there may be
some small advantage, but an increase in the amount of RAM for the server or
having a separate DB server from the web server will be a much better
investment in boosting performance. No, my feeling about stored procedures
is it is a way for DB vendors to lock in users - absolutely counter to
open-source philosophy. I am confident of Dick's input here and I will of
course listen to reason. I worked extensively with MS SQL Server
storedprocedures and DBCC update statistics before every run does tend to
slow performance - I guess things have come on a little since 6.5 but a sour
taste does tend to stick in the throat for some time!
Irrespective of that, to make the application most portable the SQL should
be as generic as possible. There may be scope for improving this - eg. I
tried to ensure all data and time work is done in php rather than SQL
functions to avoid proprietry functions.
Phil
|
