From: skaill <sk...@ro...> - 2004-09-20 09:09:14
|
One less complication by using char = Y or N for boolean. Works will all databases and ready made for reports too ;) Ok, it wastes space (in some implementations) but who cares about that anymore?! ODBC (1992) met the challenges of differing DBMSs and was meant to be THE abstraction layer. In my mind it was ODBC that really pushed the way for a standard sql (sag sql) to become popular. Before this each DBMS had its proprietary language instead of sql so people were hungry for ODBC. The ODBC middle layer demanded everyone use a common set of commands and a standard sql. The problems with ODBC included slowness, which was resolved to a large extent over the years and having to install ODBC driver(s) for each type of database needed on every client machine. The database vendors had to write the ODBC driver for their product and make it work in the Microsoft hidden world of Windows. So why are these other abstraction layers cropping up when ODBC exists? Steve ----- Original Message ----- From: "Jake Stride" <ns...@us...> To: <web...@li...> Sent: Monday, September 20, 2004 3:40 AM Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > Daintrees wrote: > > >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 think the reason for it is that this works in principle but not in > pratice. > > > Take for example inserting booleans into a database, postgres represents > them as 't' and 'f' whilst I believe mysql represents them as '1' and > '0', so already you would have to wirte a function to deal with this, > and on it goes until you have your own abstraction layer. > > If you are using auto_incrementing/serial fields for ids a database > abstraction layer can use the native functions for those dbs that > support it but implement its own functionality for those that don't, > therefore using a database abstraction layer you can simply call > $db->nextId('tablename') > > I think it is 6 of one half a dozen of the other, if you do not plan on > using to many advanced db features then the ConnectDB method is fine, on > the other hand you can let somebody else deal with the abstraction who > has access to several DBs and a developer community that is working > solely on the task of database abstraction and not have to worry about > new features bugs etc yourself, simple upgrade the abstraction layer as > and when. > > I have taken some of my examples from > http://creole.phpdb.org/wiki/index.php?node=8 there point about quoting > is a good one too. > > Jake > > >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 |