Rod,
Rod,

>The application listed is the DSS application (data warehouse)
>The OLTP application should show up on the list sometime soon. It has comparable data sizes to the DSS application and uses stored procs exclusively. Like all sql server apps should.

1. First you say that you should not use DBFs anymore, but something else like SQL Server or MSDE.
2. Seconds you say that when using SQL server you should use SPs.

>>So how the hell would I implement an application that is backend >>transparent. The fact is that RVs do add a transparancy layer to the >>design with SPs do not. Your argument does not make sense to me.

My answer to this is: I wouldn't. I don't engineer my applications to be back end transparent. I am not SAP, Peopleware, Siebel or another ERP vendor. Engineering an application to be back end transparent is too costly and most clients wound not justify that expense.

Also you are not being very realistic on this one. The differences between oracle and sql server are great especially when it comes to data types. Generic back end transparent applications cannot take advantage of the cool features of a database. Like Oracles Java stuff or SQL Servers XML stuff.


On to your second long winded points.

You sure assume a lot about what I do as a developer and what I know as a businessman. I am well aware that there are lots of mom and pop operations out there. I am also aware that supporting them takes just as much effort as a large client. I don't like working in that market. So I cede the mom and pop market to you. You win! No competition from me.

Next you talk about standard software (what I call shrinkwrap or commercial software) and how it is much different than custom client software. You claim that it is more complex to develop, has a greater # of ER's, etc. You also claim that it is more difficult to write. You are incorrect. It is no more difficult to write a shrinkwrap app vs a custom app. The requirements are different. That's it plain and simple.

BTW, one million for an ERP package makes me think that what it does is trivial. My guess is that SAP, Peoplesoft, Siebel, etc. Spend more than that in a week.

>>I do know from experience that you have to have very decent skills to >>write a decent standard software package, while about every idiot can >>write custom made software: As long as the one client is happy it does not >>matter how the architecture looks like. And if it was rotten to the core, >>you just say, we need to do extensive programming to build this feature, >>and the client most of the time has no choice than to accept the >>consequenses.

>> Your and JVPs standpoint do simply not make sense in this world.

You are way off base here dude. You assume that all custom apps have poor architecture. How do you come to this conclusion. Let's see: how do you take a 60GB application and go to over 800GB in 5yrs with a bad architecture ? I guess I was lucky on that one.

>>How different is the other world where you have to crawl
>>into the
>>problem domain, to understand the business domain, to write
>>solution
>>that anticipates on clients requests and have a solid and
>>flexible
>>design.

Is this not what we do when building custom applications ? How is this any different? Please enlighten us all.

>>Your and JVPs standpoint do simply not make sense in this world.
Let's see: Use SQL Server (or Oracle) Stored procs, Use VS.NET. Don't use DBF's. Guess that is my standpoint then.


Have a day,
Rodman