[discostu]

I believed him and still do. I just read it differently and that happened to be how he meant it. When I see someone say it took X time to code and test something in language X I intuitively think they're factory in back end and design. Maybe it's because I've spent my whole career in a MS world. One of the big things MS works towards is lowering the boundaries between applications, so even if the person only mentions the front end I know back end work was in there. And if somebody says "code and test" I read that as the whole development process from customer wish through final deployment. If they just say code that's different, if they say code and test that usually refers to the whole process.

We didn't assume he was being inaccurate, we assumed he was using linguistic shorthand to refer to an entire process without having to type in every little thing which fellow professionals know already is included. Maybe you just don't spend enough time in design meetings, that seems to be where we all learn this shorthand.

I believe in single DB backends. Multiple backends means lots of itterative testing which is expensive, and the testers hate it because it's boring. As for the number of tiers, I learned long ago that you just dig 3 tiers. When you see 3 tiers you see flexibility and speed. When I see 3 tiers I see 50% more possible failure points. Everybody's gotta make their own decisions.

[Dominic Harr]

I just read it differently and that happened to be how he meant it.

He specifically said one thing, and ya'll "assumed" he meant another. We were specifically talking about code migration, he specifically was talking about code migration, but you assumed he didn't mean coding and testing when he said coding and testing.

Okay, whatever. It can be hard to admit error, I understand.

As for multiple DBs, that's an absolute must in any real environment, in my experience.

If only over time, you will have to migrate DBs. There's almost no way that 5 years from now they'll be using the same version of the same DB.

And certain DBs are better at some things than others. For massive data load, you have to use Oracle. For smaller DBs, SQLServer can be fine. Or even MySQL, for that matter. Or even Access, in some cases.

And then there's the whole "executives live and die by that stupid Lotus Notes/Domino DB" thing. All our HR data is in a Lotus Domino DB.

The idea of forcing all other depts to go to one monolithic DB is completely unworkable, in my experience. For political reasons, for organizational reasons, and because the people who use the data should "own" the data.

A real business has to be able to report on a wide variety of data from a variety of sources.

This is one of the really good uses for a C# 'web service', and that's what I'm playing with now. I've got a MySQL db that stores all the 'game world' data, and an applet that communicates with the game world thru an XML-based middle tier.

I only wish I didn't have to use IIS. I just can't stand that product, and am reminded why a hundred times a day.