[support] Seeking Advice on Integrating drupal

[Ivan Sergio Borgonovo]

On Tue, 27 May 2008 08:39:22 -0400
"Christopher M. Jones" <cjones at 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