Menu
▾
▴
Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap
|
From: skaill <sk...@ro...> - 2004-09-20 20:53:20
|
In theory 3-tier is a great idea, however it has some drawbacks too. I don't know of a system anywhere as near as complete as webERP that has true 3-tier separation. An accounting system in particular is critical to a business. It must be very, very reliable. For this reason, typically you will see less than state of the art at banks and government for instance. Someone's neck would be on the line if things got out of control and they can very easily. There are some other important reasons for carefully considering the approach. Many who will put their attention toward webERP will be accountants who may not be computer experts like us. Going too extreme can alienate them from contributing even though they are the ones who more likely understand the full extent of deeper accounting problems. What I'm saying here is I think it's a fine line and a line that, in the interest of keeping the product stable, bringing more people on board and keeping people onboard, needs to be moved slowly. Side note: While I do believe in isolating the business rules, I do not believe planting business rules in the triggers of a database or in stored procedures is beneficial, I would keep them in code. Triggers and stored procedures lead to bits and pieces everywhere. Steve ----- Original Message ----- From: "Stins, Dick" <DR...@Zi...> To: <web...@li...> Sent: Monday, September 20, 2004 4:29 PM Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > Yes, any technical database layer is not that interesting, although it's > always handy when it is not too much work to move to another database > engine, but I see no need to change from mysql to another database engine at > the moment. Solution like pear:db seems only to slow things down and hide > the real code and creates more trouble when in pear:DB (or any other > wrapper) are some bugs. > > When I talk about a database layer, it's functional. Like you have a > function to delete a customer. > This functions checks all business constraints before deleting: > - are there any transaction related? > - are there any open orders? > - are there any companies related to this customer? > - is it an active customer? > - is it bankrupt? > - ... > > When one or more checks fail, then the function returns an understandable > error and refuses to continue. > > When you have this function, then you are able to call it from any script, > like a delete script, or a batch script which deletes lot's of customers, or > a webservices which tries to process delete the customer. > > The same for a create customer function. When all attributes (credit check, > address, chamber of commerce number, tax number, telephone number, > bankaccount number, ...) of the customer are properly set, then the status > of this customer will be valid. > > When you have one set of functions/methods to set all these items, then you > again can reuse this code (CLASS METHODS) of lot's of places. > > When you have a problem with creation of customers, then you know you where > to find the one and only place where it was coded: in the data layer > (customer class). > > Where all rules are coded is not that important. You can use php classes, > php functions, sql, database triggers, stored procedures or foreign keys, > column constraints, table constraints, ... > Just collect everything for manipulating customers and put them in the same > place where you can call it from everywhere, so you need not to code it > twice and test it twice and debug it twice or more. > > Use this principle for every object (table or combination of tables or ..). > Every developer would know where to look when there is a problem with the > process creating or deleting or updating a customer. > > When someone still would like to port the software package to another > database system, then he has only to port the database layer and is not > disturbed by the presentation layer and ... > > Resume: the above principle/architecture is based at two ideas: > 1. you always knows where to find object (table) related functions, so you > are not attracted to code same functions again and again but just calls them > again > 2. you only code once the business rules and are able to reuse them several > times by calling them from several php scripts, batch scripts, webservices, > .... > > With best regards, > > Dick Stins > > ----- Original Message ----- > From: "Daintrees" <p.d...@pa...> > To: <web...@li...> > Sent: Monday, September 20, 2004 9:24 AM > Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > You'll have to excuse my naievety (and poor spelling) since most of the > > native functions are similar in function but different in name for > differing > > DBs why does one need such a lavish abstraction layer why won't a > > ConnectDB.inc calling the native C calls to connect directly for other DBs > > do the trick? This way we have ultimate performance minimum overhead! > > > > I really don't understand why such lengths are necessary - the function > > calls are virtually one to one and even most of the parameters are the > same. > > > > MS SQL Server > > > > mssql_connect > > mssql_fetch_array > > mssql_fetch_row > > mssql_data_seek > > > > > > MySql > > > > mysql_connect > > mysql_query > > mysql_fetch_array > > mysql_fetch_row > > mysql_data_seek > > > > Postgres > > > > pg_connect > > pg_query > > pg_fetch_array > > pg_fetch_row > > pg_data_seek > > > > > > Firebird/interbase > > > > ibase_connect > > ibase_query > > ibase_fetch_assoc > > ibase_fetch_row > > > > whoops there is no > > ibase_data_seek > > > > maybe I'm answering my own question! > > > > > > Phil > > > > > > ----- Original Message ----- > > From: "Jake Stride" <ns...@us...> > > To: <web...@li...> > > Sent: Monday, September 20, 2004 5:58 PM > > Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > > > > Stins, Dick wrote: > > > > > > >Jake, > > > > > > > >Thanks for your comments. > > > > > > > >I am not a fan of pear:db. I prefer to use standard sql. That is > already > > a > > > >big step for portability + the clean and mean weberp script > > ConnectDB.inc. > > > >So it should not be too hard to port web-erp to another db engine. > > > > > > > > > > > No to be honest neither am I, for reasons I won't bore you with it was > > > chosen at the start of the project and has persited through. Have you > > > had a look at > > > > > > http://creole.phpdb.org/ > > > http://propel.phpdb.org/wiki/ > > > > > > >Smarty might be interesting, but I am already glad when css is optimal > > used. > > > > > > > > > > > This is the case with EGS, it just allows all of the presentation logic > > > to be removed from the code base and allows people to be a lot more > > > flexible with the layout without having to trawl through the PHP code. > > > > > > >Multiple company support is interesting. > > > > > > > > > > > Yes this was one of the distinctions that was used to justify it over > > > simply contributing to an exisitng project since non of the others do > > > it. For this reason I am not sure if one of the Application Frameworks > > > would have worked due to its authentication system. > > > > > > Have you looked at http://www.binarycloud.com/ > > > > > > >Does it also support ldap (nds)? > > > > > > > > > > > Not at present. My knowledge of ldap consists of the following: > > > > > > It exists > > > It is adirectory server > > > > > > I have always thought that it would be good to have it working with ldap > > > but unfortunately I have not had the time to look into it. However with > > > the present system I believe you can use PEAR:DB to connect to ldap so > > > may be possible. > > > > > > Thanks > > > > > > Jake > > > > > > >with best regards, > > > > > > > >Dick Stins > > > > > > > >----- Original Message ----- > > > >From: "Jake Stride" <ns...@us...> > > > >To: <web...@li...> > > > >Sent: Sunday, September 19, 2004 7:41 PM > > > >Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > > > > > > > > > > > > > > > > >>Stins, Dick wrote: > > > >> > > > >> > > > >> > > > >>>Jake, > > > >>> > > > >>>I think that common functions which are needed in weberp and in your > > crm > > > >>>software should be encapsulated in classes, so you do not need to > know > > > >>> > > > >>> > > > >where > > > > > > > > > > > >>>the information is comming from (postgres or mysql). > > > >>> > > > >>> > > > >>> > > > >>At the moment it kind of should be in that it uses PEAR:DB for > > > >> > > > >> > > > >abstraction. > > > > > > > > > > > >>>When you want to > > > >>>integrate web-erp and your crm software, you still need to integrate > > the > > > >>>authentication and the address books processing and .... > > > >>>The design of these issues should be loosely connected or we should > > > >>> > > > >>> > > > >create > > > > > > > > > > > >>>one big project (wegs-erp?). > > > >>> > > > >>> > > > >>> > > > >>> > > > >>That could be interesting and worthwhile, is it something people may > be > > > >>interested in? > > > >> > > > >> > > > >> > > > >>>The same for all your code which needs views. Those should be > > > >>> > > > >>> > > > >encapsulated > > > > > > > > > > > >>>in classes, so it's easy to write an alternative for mysql > > > >>>(allthough when you are able to run mysql with maxdb, then probably > > you > > > >>> > > > >>> > > > >can > > > > > > > > > > > >>>use views). > > > >>> > > > >>>I even recommend to develop an architecture with: > > > >>>- front end layer > > > >>> > > > >>> > > > >>> > > > >>> > > > >>Smarty for templating > > > >> > > > >> > > > >> > > > >>>- business rule layer > > > >>> > > > >>> > > > >>> > > > >>> > > > >>System is written as classes > > > >> > > > >> > > > >> > > > >>>- database trigger layer > > > >>>- database layer > > > >>> > > > >>> > > > >>> > > > >>> > > > >>PEAR > > > >> > > > >> > > > >> > > > >>>This helps to be in control of you own code, reuse of code, increase > > > >>>portability for you code (like porting to other databases: sql > server, > > > >>>firebird, oracle). > > > >>> > > > >>> > > > >>> > > > >>> > > > >>EGS should work in oracle without much trouble because of PEAR:DB > > > >> > > > >> > > > >> > > > >>>An example of an architecture like this is: > > > >>>http://sourceforge.net/projects/seagull/ > > > >>> > > > >>> > > > >>> > > > >>> > > > >>I did have a look at these, the problem is that EGS authentication is > > > >>more complicated that this. It is written as an ASP application so > that > > > >>several companies can use the same server/DB etc. > > > >> > > > >>IE in egs one company can login and create there own users and groups > > > >>and insert data etc that another company cannot see. > > > >> > > > >>Jake > > > >> > > > >> > > > >> > > > >>>With best regards, > > > >>> > > > >>>Dick Stins > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------- > > > >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > >Project Admins to receive an Apple iPod Mini FREE for your judgement on > > > >who ports your project to Linux PPC the best. Sponsored by IBM. > > > >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > > >_______________________________________________ > > > >Web-erp-developers mailing list > > > >Web...@li... > > > >https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > > who ports your project to Linux PPC the best. Sponsored by IBM. > > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > > _______________________________________________ > > > Web-erp-developers mailing list > > > Web...@li... > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
