I appreciate everyone's advice. You've been very helpful. I suspect that our spec probably is less rigid than what I made out. We'll know more as we find out more about what this client actually wants. Either way, I think we're still pushing for Drupal.
There's just one last thing: what are we going to face as we look at implementing a sell cart? That is, in addition to the traditional buy cart, where customers save items they want to purchase from the company, we need a sell cart where customers place items they want to sell to the company for a set price. Is this going to be a quick hack, or not?
On Wed, 2008-05-28 at 10:52 +0200, Ivan Sergio Borgonovo wrote:
On Tue, 27 May 2008 08:39:22 -0400 "Christopher M. Jones" cjones@partialflow.com wrote:
Very helpful. Thank you. In view of the fact that precisely what we're looking to avoid is the cost of creating a new engine, what about other solutions? We like Drupal. And if the tweaks we need were simple we'd love to contribute. But if that's just not realistic, then what about eCommerce? I steered clear of it, because reviews of it seemed a bit luke warm. And then there's Zen Cart, which I can't really get a good feeling for, since they seem to have removed their documentation so you have to buy their book. That doesn't give me a lot of confidence.
At a first sight none of them actually reach that level of "consistency". I'd like to sit down and just see pieces of software gluing up by themselves and get the money for my contemplation of the Open Source Universe... <g> but since I had strict requirement on constrains on orders I had to sit down and write my own e-commerce engine and I used Drupal at where it is good at: CMS and community plumbing... plus the fact you get form validation and anti-tampering, theming... and PostgreSQL at where it is good at (coherency, transactions, fun to program).
If your MS SQL box is in proximity of your web server (to avoid latency etc...) you may put the e-commerce logic in MS SQL and use Drupal with mysql or postgresql as the display layer. That's exactly what I did at the beginning. I think putting products in nodes and recycling taxonomy doesn't offer enough advantages compared to performance impact and it can't be tuned as much as a general e-commerce site require (at least... integrating nodes and products in a good way required more time than just writing a "product" hook). If you need full text search on the catalogue you'll end up using the one offered by the DB if you've a high traffic website. MS SQL have a pretty different logic for paging and I think adodb drivers are the ones that exploit it better.
Zencart offer a basic CMS as other products do. I was looking for a more complete CMS.
Without Drupal and PostgreSQL I wouldn't have been able to write such feature rich software in such a "short" time. You may: a) reconsider your requirements. Are they really so strict? If the traffic is not going to be so high etc..., the chances that someone will order the same products at an enough near time to cause inaccuracy may be negligible. One thing is displaying the available quantity at a certain time, another is closing an order trying to avoid "overbooking", another one is closing an order *being sure* you didn't "overbook". b) write your own solution. This is not going to be cheap and you'll have to consider Drupal release cycle and your development time and your "time to market". c) dig deeper in Ubercart/Zen/OsCommerce and prove I was wrong and they can actually be tuned to meet such strict requirements in a 2 DB scenario or they already do what you need.
If you chose b) you could:
- use mysql/postgresql as Drupal DB and MS SQL as the e-commerce
engine DB. This is a feasible choice just if your MS SQL is in proximity with your web server. Consider also security concerns. You'll end up in exploiting some of the characteristics of the DB because you'll need transactions and locking etc... When you'll need more Drupal/e-commerce integration... porting your code from MS SQL to pgsql or mysql may take time.
- write your sync logic and move everything in mysql/pgsql.
Still, if you *really* need up to the second inventory and your data are on a MS SQL server you're going to write your own purchase logic to be sure that orders contains really available items. The most frequent scenario is... they have their 3rd party closed source accounting application on that MS SQL and this is not going to help.
The really most frequent scenario is... they don't have such strict requirements and Ubercart + Drupal may be your best bet.
-- Ivan Sergio Borgonovo http://www.webthatworks.it