Compiere on Postgres/MySQL
Tim Griffin writes " Compiere (arguably the most comprehensive open source ERP/CRM solution) has recently taken an interesting approach to harnessing community support for adding database independence to their product (currently it requires Oracle). They are taking pledged donations to help get the ball
rolling on the project
Certainly there are many feature requests in OSS I'd gladly pledge towards. Is this feature pledging a sustainability model for opensource developers/companies? Other examples, such as
Blender3d which raised 100,000 EUR in 7 weeks, point in that direction. Perhaps in the future we may even see these pledge requests
linked within the GUI itself? "
I didn't know what this was, so from their webpage:
What are ERP Software Solutions? ERP stands for Enterprise Resource Planning and is the software to support your entire business processes. ERP Software Solutions typically consists of modules such as Marketing and Sales, Field Service, Production, Inventory Control, Procurement, Distribution, Human Resources, Finance and Accounting.
What are CRM Software Solutions? CRM stands for Customer Relationship Management and is the software to support your business process to find, get and retain customers. CRM Software Solutions typically consist of modules such as Sales Force Automation, Call Management, Self Service.
PostgreSQL is more feature rich than MySQL. Whether or not it's more "advanced" depends on what you are using it for.
And no, I know MySQL has transactions through InnoDB, however MySQL doesn't have stored procedures, which also means no triggers. PostgreSQL not only has procedures but it has inheritance, overloading, and support for pl/PHP, pl/Perl, pl/Python and a host of other languages you can write stored procedures in.
Theres a bunch of differences between MySQL and PostgreSQL, neither of which make either one better overall. It's a matter of the application of each which determines if one is better.
..There's a-dooin's a-transpirin'
Mr. Janke wrote this code originally as a Java based Oracle project back in the 1990's in Germany, and somehow he got to keep the code license. So it is very 'tied to Oracle'. And it wasn't built to be 'portable'.
:-(
The 'issue' is some form of 'stored procedures', but I've not the background in Oracle to do the work to de-Oracle it, or to know enuf to know what I'm looking at.
Really? Have you tried setting up postgresql? The version in RH9 was just as easy to set up as mysql, so if that's a PITA, you're not going to believe what you need to do to get oracle to work ;)
1. Because it hasn't gotten anywhere near the airtime of MySQL/Postgres.
2. Because it is going away -- being merged into MySQL AB's product line as MaxDB.
http://www.sapdb.org/7.4/sapdb_mysql.htm
Learning HOW to think is more important than learning WHAT to think.
I don't know if you have EVER use an enterprise applicaiton before.
:)
No, you don't know. I have. I've worked quite extensively on an ERP application called PeopleSoft. It locates all of it's business logic in the middle tier. The SQL it produces is very database agnostic and will run with minor modification on most database platforms.
Even if it IS just select/inserts/deletes for basic GL/AP/AR applications you are talking about people, systems and components requiring gigs to terrabytes of data and hundreds if not THOUSANDS of concurrent users.
Yes, and basic SQL is more than sufficient to support this.
MySQL can't handle flash back transactions, doesn't support load balancing, hot site, and paralell or clustered transactions. I need all of these to support an enterprise environment!
Who said anything about MySQL, I believe the article was about Postgres. Regardless, or production AP/GL application supports hundreds of concurrent users without any of these features (at least not in the database layer) - so you clearly don't need them to support an enterprise environment.
oh well. You have to remember that big business is alot different than hosting a small website or cddb database on your average linux pc
Thanks for the lesson. I'll have to leave now because I have a production PeopleSoft issue to troubleshoot on our 10 CPU database server.