Database

[Astaroth]

I (aka the missus) has an idea for a new B2B service but unfortunately it goes beyond my level of programming knowledge to fully impliment it (it isnt a basic ASP website)

Effectively what the service would need to be able to do is cross reference certain elements of their order system to a database maintained by ourselves and send a report to them.

For all advanced orders it would be possible to do it in downtime/ by batch (if these terms are still used) if this was "better" these would be the majority but would also need to be able to give realtime responses for non-advanced orders (which would be a significant but not a majority percentage)

My question is - given this service would be used by many different companies who run different ordering systems how difficult would it be to actually create this sort of program? I would anticipate that there would be a standard "engine" that does the work but then a small "config" type file which requires minimal expertise to set it up correctly for each client.

Regards

[Enigma121]

Astaroth,

We deal with this sort of distributed B2B system, so are in a position of estimate the effort required.

Some questions to answer first.

Are the client databases all of the same type? Do they have common access arrangements? If not their is a substantial bit of configuration or "just in case" coding required to make things adaptable. This is the most fluid bit of the work.

Once you have common clients sending data back, you need a robust server to handle the traffic and send the reports out. So you'll need to gauge the number of clients connecting, to size the server appropiately.

Does this help?

[Astaroth]

In the present thinking I would imagine that there are basically 2 varieties of the solution.

The first I can see working easily/ well and could arguably be along a similar lines of how a number of the online colaborations of estate agents have worked - ie they develop a desktop application for the day to day running but then add the new dimension of it connecting up to the central database to share the information. This I imagine would be a relatively straight forward solution to develop with the only difficulty being migration of data from current system to the new solution.

The secondary is much more difficult and more what I would need to scope out. Approaching a SME and getting them to switch isnt going to be the hardest thing given the new proposition aspect. For larger enterprises I dont believe it will be realistic to get them to switch systems and even if it was then the solution would effectively need to be too rigerous to be realistic for development. Therefore I would anticipate a bolt on system that uses their existing databases as their source but whilst these will have the common data which we would need to cross compare their structure and technologies are clearly going to vary.

I have experience of approaches with my employers of companies offering an off the shelf bolt on to our mainframe system (which is bespoke) with a colaboration between our and their IT specialists working on the intergration. I would imagine option 2 following a similar vein.

At present solution 1 is viable but for it to be effective and therefore attractive at least a number of the larger players would need to sign up to the service which is why I am trying to gauge the complexity of solution 2

[crus]

Your defo on the right direction in my opinion.

I'm in the last throws of a price compairon system, which sources from XML, CSV and plain text files dependent on the client.

My favourite bit (blow my trumpet) is the custom xml parser I have written overlays the merchants profile data over the xml and utelises our in house schema to validate the data before it is accepted into the system

The process you are considering may seem, complicated, but once you break down the constituants it will be a lot easier than you first thought.

On the DB side, I would lean towards MySQL, but get it running on a nice isolated machine that is a pure number crunching linux box, clone the box so you have failover and then run the reports from the cloned machined to totally isolated your core db.

I use Apples Xserves for my db work, as they avoid many of the thread limit pitfulls I have had elsewhere and have phenomenal crunching power on a bang for buck basis.

Hope this helps keep you on the right track!

D