DavidM

Someone buy this man a coke.

If you store all your business logic within the database, then it doesn't matter what flaky applications people write you can guarantee the integrity of the data.

Big up.

As I SV, we have a lot of customers that will only use one RDBMS, the problem is that is it not the same one. Every time we put some “logic” in the database we have to write it as least two times. We do use foreign keys when every we can, however we do not use triggers to check logic, as they are two hard to write for every RDBMS our customers have. Foreign Key on views would be VERY useful, even if only one RDBMS had them. We see Foreign Keys as an automatic test of our BLL, e.g we should NEVER fail a database constraint, and only do so then the BLL has a bug.

The BLL needs to be close to the UI, as it is the job of the UI to prevent a user from choosing a invalid option, BEFORE they press the “Save” button. A BLL that is in the database, only tells you that a given choose is not valid, after then user has pressed the “Save” button.

Everyone will have an opinion on this one, here is mine.

I view data integrity as VERY VITAL to the succes of any application. Corrupt data can cause bugs and potentially security holes throughout software.

I view the business logic as a way to check current incoming data before it gets to the database. For instance, if I need to check to make sure that the current user is allowed to insert the record, I would most likely do it both at the database and the business logic. Double work, but where security is concerned, you can never be too sure.

Most other business rules that I need to implement are things like, if this occurs then do this. The only time that a business rule like this (workflow) would not be in the database is if the database does not have direct access to the next step in the workflow.

UI presentation is a third layer of protection, to make sure that the user is only entering valid data that will make it all the way into a table. I would and will not ever rely upon UI validation as a means of business rule management.

So in part, if you do not need to target different database vendors and you know what you are writing for then I would say, make use of the database as best you can to validate EVERYTHING, not trusting one bit of the information coming in.

Same goes for the business services, and the UI data validation.

NEVER TRUST A SINGLE BIT, NIBBLE, OR BYTE. :)

Rage on! Great post.

In the bag tonight: .NET: 9; Admin: 1; Blogging: 2; Dev: 7; Perl: 1; Rant: 5; Securoty: 1; SQL: 3; Tools: 2; Writing: 2; WTF?: 1; WILY: 3; XML: 5.
Line of the night:

I disagree with the entire concept of "relational database modeling". Putting the code inside a database model is stupid, dumb and causes the development team to plod along putting a dynamic reality (changing world of how a business works) into a static database structure(ERD Definition).

The structure of the database (definition) is STATIC, the real world (Business rules are dynamic). The entire basis for SQL relational database is based on the flawed premise that a database modeller can put business rules into a static design that will meet the future needs of an organization. You can't redefine and reload a database as easy as Oracle states in the real world. You often have to redefine all the table relationships and reload the entire database structure when the "organizational needs change". This causes huge headaches for complex systems.

There is a HUGE FLAW, (you could read straight jacket) that is put on the the programming staff that "must" code within the constraints of the database model.

How should a database be designed? The data should exist in the database. The procedural code (design of the database in relation to the use by the organization) should exist in the programs, as much as possible. Yeah you still need keys of the most basic nature, like keys in a VSAM file for objects, but not relationships or foriegn keys at all. All the constaints of a relational database and real world reality of "non mutating table principle" that causes the artificial need of more tables is a bunch of B.S.

Now we see relational HELLS everyday in the real world. Databases that are not designed or overdesigned. To design a proper high level database, you end up having to use "non-meaningful" keys and reduce the level of "normalization" which is the same thing as saying your designing a flat VSAM file structure in SQL relational design, but accessing it through a slower supposedly relational design.

The entire theory of relational database is flawed in it's execution, because it theorizes that the dynamic changing organizational needs can all be put into a static definition. Sure you can redefine foriegn keys and constraints as the organization changes. But we find that it costs 10 times more to maintain and code in "solutions" like Oracle compared to legacy code. All to "keep the data pure" and "keep the garbage out", etc. It's a bunch of bunk. Less than 15% of the code in a legacy Cobol system (hierarchical) is for validation of data and cross validation. I did a study in the real world (State of Michigan) against programs that run against some of the largest IMS/DLI databases in the world. This showed that only 10 to 15% of the code in our programs was for simple and cross validation. So to save 10 to 15% of the code and keep the "data pure" and remove garbage. Instead of coding the programs correctly, relational theorists and practicing shops end up sufficating programming productivity to save 10% of the code. The thought that you can analyze the heck out of a business and spend months or years designing a proper database, forseeing the changes of how the organization will work is pure FICTION. In reality, it just costs many more times for the company or organization to maintain the database, keep all the DBA's employed and watch a sea of wannabee Oracle programmers attempt to code solutions that the users end up hating and cost 10 to 100 times more than the legacy code they replaced.

I think Oracle is a company that lies outright, overhypes their product and companies have bought it because "everyone else has one". Just like Nuclear reactors were "popular" so is relational DBMS products. They work, but they don't work correctly from a ROI (return on investment) perspective. It's a huge house of cards and hot air. 90% of the relational programmers and DBA's don't even need to exist. Where I work 90% of the real world programming is performed by legacy systems written years ago and many millions of dollars of Oracle conversion and projects have only scratched the surface of the "real world" work going on by legacy programmers. What happened to the legacy staff? They layed off or retargetted them and only about 10% of the staff that once existed runs the old system, keeping it running and doing the work. While the rest of the staff (new technology) end up doing small projects with little actual return, and promising to deliver an Oracle or other new technology solution someday in the future. If I was CEO of our business(but we're not a business we just waste taxpayer money), I'd get rid of Oracle products altogehter and curtail "relational" development to a minimum for simple projects that impress "manager types".

You guys who worship at the alter of "relational design" are fooling yourselves. (But at least your making a living at doing it.) :)

Greg

Thanks for feedback Greg.

You seem like an angry man.. Are you sure your not a DBA?

The basic premise for your "dislike" of RM seems to stem from the fact that you equate RM with modern products. The closest to a true RDBMS is probably Alphora(sp?) while SQL DBMS are NOT EVEN CLOSE to the principles of RM. Your arguments about a static structure are confusing...How a multi-dimensional, time varying "object" be considered "static" is beyond me. It seems you are dismissing theory because a business model you have worked with is inflexible..

I have to wonder if you even know the history of data management and why RM was considered a revelation. The comparison with IMS/DLI is telling, your arguments are nearly 30 years out of date and where rejected in the mid 1970's. Look up the "Great Debate" to see for yourself...

I am sorry, if the organisations you work with upgrade for upgrade sake, but to base poor implementations as the foundation for attacking a theory is just silly. It is like blaming Pi when you can't draw a perfectly round circle..

To counter point your main argument, in the shop I am currently at, the number of databases is less than the number of applications that access them. This means that multiple applications, both inhouse and external, interact with our SQL DBMS.
Without good data integrity enforced at the database level, the value of the database, its application and the business it self would be seriously jeopardised. The business is extremely volatile, with monthly upgrades to data and application rules...Funnily enough the data management team has the least staff...

I've read some other threads in the forum and must admit there are a lot more "experts" in many of the relational products and products than myself. It could be a blind spot of mine. Here's the basics of my points. I could send you a paper (for my own analysis) that I created which covers the arguements I've formulated in my own mind. I'm open to criticism and correction if I'm to much of a newbie and I'm missing something. You'd think being a COBOL programmer for 8 years, a Lan administrator for 5 years and an Oracle developer for 5 years would make me somewhat educated, maybe I missed something somewhere. I've coded in a lot of the third generation languages in school. Even created a language in one of the classes I took in college. I've played with and supported MS Access. I've seen a lot of analysts and managers take classes in relational products like MS Access, do a few simple exercises in class and never complete a complete ERD phase of analysis or do any work in relational database beyond class. And these are the biggest proponents of "how great" MS Access and Oracle are, etc. They talk like they are wonderful products, but interestingly enough then end up not actually doing anything useful and productive with them. I have tons of stories, but who has the time to go over them.

Sorry if I seem harse or angry. I'm just upset, mostly at the Oracle product and how (unfriendly it seems to be).

HERES WHAT I MEAN BY STATIC DESIGN

To try to be more clear I'll explain a project that I worked on briefly and give a couple of examples. This project was a conversion from a 4 or 5 table MS ACCESS database into an Oracle database that required many tables, about 20 tables to be exact. We looked at the business model (an experienced relational consultant, myself and an Access programmer), talked to the users. This was for a simple system with about 6 users. The original relational design was lacking in being "normalized enough" you might say it was a good collector of GARBAGE. It technically was inside a "relational database", but was a huge garbage collector.

By analyzing the heck out of the system we came up with a "relational" model that met the needs of the business. Unfortunately the organization was changing in the future and part of the model was built to directly meet the hierarchical structure of the organizations ORG CHART.

The ORG chart of an organization and how it works "at one time" is STATIC. This is what I mean about a static structure in the "real world". The database tables in the ERD design had to match static definition of the Org chart to meet the design requirements of data entry. For example "BRANCH OFFICE number" in a branch office number table. So we define the "perfect" ERD or table relationship. Which would be defined in ANY relational database product, not just Oracle. Well during the definition, the consultant says something to the effect that, we think in the future the "Branch Offices" will be going away and the organization will be changing into a different structure (a different org chart) that uses "regions". So we need to create a "region" table, not a branch office table actually two tables and link them, the second region table that references the branch office table in the present and can work in the future.

My point is, the static snapshot of the organization was codified in the design of the database itself, because we are using MEANINGFUL keys in our ERD. This is relational theory.

Now some "experts" would say, don't use meaningful keys (instead use non-meaningful keys and have alternate keys that are indexes. . .sorry my terminology is a bit off here. But my DBA insisted we use meaningful keys for efficiency sake. So we end up coding a solution that has code values or relationships that match a snapshot of the current reality, but might not fit into the reality of the future of the organization, because when it changes, and it does the ERD needs to be able to meet the FUTURE status of the Organization. Not only do you have to design a good ERD, you also have to FORTUNE tell about the future to create a decent design, amazing indeed.

The ORG chart changes and because we're coding tables with relationships, the KEYS and foriegn keys that have LOGIC in them. Because the logic of checking for a valid value, either by key definition or constraints is now coded in the database definition itself; the database definition itself, the ERD has programming logic in it's definition. HERE'S MY BEEF. The entity relationship diagram is STATIC. It's UNCHANGING. Yeah I can add a field to the ERD, but I can't change the keys or relationships while it's running and loaded in the real world of Oracle.

Now we can change this definition supposedly by redefining the database later. But my point is, once the database is loaded, you can't redefine the table and change the key definitions and foriegn key definitions, without doing a complete reload of the data.

My main point is, the STATIC DEFINITION of logic (logic should be in the programming language) is put into the structural definition of the database. That's my first problem. Maybe it matches the earlier arguements that supposedly were lost when Dr Codd first came up with the theory. Have these flaws been addressed yet? I don't see a solution in the products What have I been missing? Maybe your right, but how has the "relational" crowd won that arguement? By using "nonmeaningful keys" and indexes? Well that's functionally the same thing as having a FLAT VSAM file with alternate indexes.

So Oracle and other SQL/RDMS vendors start out by saying, you can use a meaningful key when you define a database and foreign keys, and here's a little example for you. They show a simple example. Then when you code in the real world, you find out the "meaningful keys" in a fully normalized database is in fact, logical computer code in the design of the database. Now when you need to change the logical function of the database(something that requires key changes), you need to do three things:
1. You need to change the logic in the program.
2. You need to change the structure of the database.
3. You need to reload the entire database.

When all the programmer should have to do is:
1. Change the logic in the program.

Now I know that hierarchical structures at time need to be changed, but it's much easier to change them. (That's what filler space is for, that's where the concept of Optional feature list like logic came from.)

Since it takes 8 hours to load the 20 or so tables of this simple 2,000,000 record system (2,000,000 record in the original 5 table MS Access system), I can only imagine how long it would take to load a REAL large enterprise wide properly conceived and designed database for the entire agency I work for. In reality it would take more time to load the thing that we have hours in a typical weekend. Meaning once the "big" database is designed and we have it, we'd be stuck with it. That's assumming we have 30 years of time to set aside to do a correct design for this older system that took 20 years to create and debug in the first place.

Changes to the database ERD design would be IMPOSSIBLE. Meaning the database would not be flexible.

What I need to be an efficient programmer is a database that allows me to change the programming code to meet the changing needs of the user. I don't need a database that requires itself to be remorphed into a different structure to meet the needs of the user.

Furthermore, complex designs or the tools that are developed to meet the designs like Oracle Tools (Forms) provide limits on updating table information on screens that have a one to one logical relationship to "the way the user wants the screen to exist". A user may see data in relationship to the function they need to use that data. With Oracle in our design, we found that at times we had to actually add more tables to artificially create more tables as it were, just to allow the user to update portions of the screen. To avoid, the "non-mutating" table principle. Querying records, showing them on the screen and updating rows in some of those records, for example. We had to create more database segments. The database should NEVER have to change, because a user wants to utilize the data differently.

Then there's the insult to programmers, saying we don't need programmers anymore. Oracle teachers state this in their classes. They say "programmers aren't needed" you just design the thing once and do table updates to change the system. They drive an advesarial wedge between DBA's and programmers and state that programmers aren't needed? Well if programmers aren't needed, why do we have a SQL language in Oracle? Why does it support Java? What is a SQL query other than it being a batch command/program that gets data and updates data? Oracle states they don't need programmers by calling "expert users" programmers. The "expert user" cannot often write the application in one sql command, so a real programmer has to actually code the solution. He ends up coding the solution from an ERD definition and contraints that are more like a STRAIGHT JACKET than a coding environment. Good programmers and users continue to flee these systems and retire.

I began to see that Relational programmers are looking at the limits of Relational theory and just accepting those constraints as facts. Yes they exist. But why do they exist? They exist because I still contend we are forcing a flawed approach and method of modelling of the database on a world that requires more changes than the STATIC ERD definitions can meet.

I'm sorry if this is a theorectical slam. It's just my take on the underlying flaw in the structure. In reality all programmers are not much more than glorified water gatherers, like those ancient water gatherers in Egypt that used a lever and pot to move water from a river into a ditch. Someday (in a 100 years) we won't need programmers. But that day isn't here yet.

PROOF OF FLAWS OF THE ERD
If you look at the Genexus website, they have based a product specifically to address this problem, but it's middleware with an AI algorithm, that can NEVER statistically work in the real world and their approach doesn't work correctly. Heck my agency paid Genexus consultants many hundreds of thousands of dollars to try to get the software to work and it never did. (This was part of a fiasco from a blue sky dreamer who was an appointed IT head that has now retired after squandering tons of money.)

I know this sounds like ranting. And it is a bit of a rant, because I've seen the architectural or at least social (way it's taught) flaws that exist. I submit to you that when you talk to most shops and survey them you'll find they are almost always missing their deadlines with any relational project of modest complexity. They roll out partial solutions and the amount of time work and extra wasted hours programming are huge. I know I'm supposed to jump back in the little hamster cage of programming, run around and pick up my check and be quiet. I know that game and have seen many play it.

Oracle (my main rant may be against them because I'm an Oracle programmer). Sorry I'm not a DBA? :)

The main problem I have is they ignore the flaws of the nature of relational databases and end up stating things like: the design seems so easy inexperienced analysts design a database that are not correct, and state that "this is the reason" you see many large projects fail. In other words, Oracle claims the biggest flaw is the not with their product, but in fact "your people are morons". It's basically the same thing. Oracle puts all the blame on the staff and the inexperience they have. They state this in their own books. They say "you need more learning" to correct the problem. When the problem is the nature of the STATIC ERD definition not being flexible. Since it's not flexible, the problem is never solved and managers are led to believe that the solution is to "train your staff" out of the problem. It's a complete con in my mind. Maybe I'm missing something. If I am I'd be willing to be taught a lesson by any reply. Email me at Pvideo@aol.com if you have some info on what I'm missing here. I'll look up the articles you mentioned.

Next, lets look at a recent claim in the past year where Oracle Inc. claims they saved close to a billion dollars in coding development inside their own company. Think about it, how can a company even spend a billion for computer programming? Wow! ! ! If I was spending a billion dollars on computer programming and I was using my own product I'd be ashamed to admit it. How can Oracle spend that much to begin with, much less save it? They can do it only if they are using an inefficient approach to begin with. A close look at the fine print regarding their claims shows that they saved something like $600 million projected dollars by doing reorganization and cost savings, which were not related to their actual IT(spending) costs of their data processing budget.

I mean come on, if I was the CEO of Oracle and my staff said they were spending a billion dollars on our own IT budget, I'd have to line them up against the wall and shoot them, or at least fire them all. It's unbelievable claims like this that get me MAD. Seriously. Then I see taxpayer dollars wasted on Oracle projects where I work and the spin is put out that something was actually delivered for the money wasted. My anger is related to the degree of scamming I've seen from ill managed and overspending in shops and all the wasted dollars take down agency/state and organization budgets. Then what? They send the work overseas to India, wow where a bunch of guys can chant the Oracle mantra good, but can they actually deliver a product that works (now I'm starting to sound prejudice, but I'm just stating what I've seen.)

So maybe I need to take a break from the venting for a while. I found this thread looking for something completely different and felt I wanted to throw in my 2 cents (might be adjusted to $12,000,000 if I worked for Oracle). Hey where I work I estimate they wasted enough money on Oracle to buy two 500 passenger cruise ships. Then the "budget" crisis John Engler leaves the state with causes them to slash the pay for the same state programmers who were trying to warn management they were just wasting money. It's amazing. I actually pay because of the flaws of false lies of these blue sky, non-delivering vendors and contractors. Amazing. Yeah I'm kind of mad. I'm kind of venting, but don't take it personal.

:)

Thanks for taking the time to respond. I might email you a copy of my long gripe letter if you'd like to see more informatin on my gripes with Oracle. Hey I gotta admit some tools out there are pretty slick. Believe it or not I'm a pretty big fan of MS Access and their ability to create SQL code based on the little drawings you make. Pretty cool advanced stuff. Unfotunately the MS Access product won't hold up to a serious (over 3 users in a small unit) running a moderately complex application against it for very long.

We have small departments that experience more and more problems as the MS Access databases get bigger and they need to convert to Oracle. I end up in situations being directed to push them toward Oracle, knowing that I could provide a mainframe solution in a much faster time frame that worked better. I'm not saying there are only weaknesses to the relational design, but there are major flaws and some tools like Oracle are almost ridicoulous to use.

There's a lot more griping I have written on in the past. Unfortunately (maybe fortunately) I write most of the long paper diatribes and file them away, because the bosses where I work don't want to hear it and are powerless to get rid of some products that are mearly cluttering up the IT toolset solution path.

A good toolset should be easy to use, provide good return on investment, have a minimum number of layers. Have a dozen or so commands that the programmer can learn to use and be very maintainable. It should be scalable, provide full security, etc. These are all easily met with (guess what?) mainframe COBOL programming. Oracle in almost every case is way behind hierarchical solutions with COBOL. Sure you can use DB2 with Cobol or even make SQL calls to other databases using Cobol. But I content the ERD problem will exist for these also because of flaws in RL theory and implementation. It takes genuises and fortune telling skills that rival God to create a proper ERD. And they still need to be changed.

There are some parts of this agency that have been waiting for YEARS, I mean years for staff to develope a decent model and relational programming to start. They cannot get much done for the users and the users are left waiting and waiting. With each new layer in the software (number of vendors), hardware, etc and more software choices (more languages) the solutions our shop can offer and support become slower in developing. Why? Because now we have to support 12 or more languages instead of one. We used to have 60 programmers and 40 support staff. Now we have 12 programmers and 70 or more support staff or "nonprogrammers" because they don't function and code anymore. We are providing fewer and slower solutions, relying on huge expenses to contractors who provide "half working" solutions that we have to spend years to debug, and literally forcing them down the throats of users. The users are literally told to sign off by their bosses and the political spin machine says, "look at all these things we did". I'm not saying all our projects are failures or there isn't a place for some of these products, but what I see as a programmer/analyst when I talk to users and what I see from what I hear is VAST waste and inefficiency. Most of the expert coders of yesteryear that are in our shop have given up long ago at giving any criticism, because there's no hope in anyone politically listening. Shoot to post this is probably a slight risk for me, but I'm just trying to state the truth and find a better way.

Thanks again and sorry for the long ranting style of post. I'm trying to be quick and frank (probably to frank on a message board). By the way where I work I'm part of the "tip of the spear on putting out Oracle solutions", so I don't vent off these things to users. I still try to do my best to provide solutions and keep these feelings and thoughts to myself for the most part. But I'm afraid usually the "king has no clothes" and unfortunately where I work he keeps getting a bill for the suit that doesn't exist.

Greg

I read some of the stuff on the website. Thanks for the information. Okay, here's my (hopefully) final comment.

It's not that relational theory (based on set logic) is wrong, but more that there are poor implementations of it.

That is the summary of what I feel the RL promotors state when faced with arguements against RL. I'm not saying that relational logic is wrong or that set theory is wrong. My whole gripe is with the implementation of these, yes. . .the products are lame.

Now I'm not saying they are lame because people haven't put a lot of good work into them. But I'm saying they are lame, because as an end user and using them and watching the results the ROI. They just don't deliver as promised. Heck even the way people are trained an use them is wrong. And maybe that's the fault of the IT staff. But why do they use them incorrectly? Maybe because it's to obscure and requires to much expertise to figure out how to utilize an RL implementation correctly. (Getting a good model it too difficult. Heck I've seen tons of "GARBAGE" inside supposedly RL systems.)

Now you can say that in theory with the right approach, ERD design etc, that a bunch of PHD's can provide the correct solution. But where I work, we aren't exactly full of PHD's. It's almost impossible to explain unless you've gone through the process of watching an entire ERD be developed and watch the users make changes and request new features into a system. Then you notice that even the brightest designer will make mistakes and products like Oracle (Designer) will have weaknesses that make the actual implementation of the "real world" tools, kind of weak. Heck we end up doing the changes to the system design outside of Designer after the first time the system is generated, because to many modifications are required by the DBA outside of designer and they don't feed back into Designer.

Maybe I'm just a griper and don't understand the products enough.

Yes RL is based on set logic theory and we can model anything in that theory. I'm saying yes something is wrong it the way we've been implementing it. I'm close to knowing what that is. Do you think if I offered to publish a more revolutionary way of doing programming that either hierarchy or RL, I'd be able to make money and be famous? Would a lowely programmer like me get a PHD? Is it worth it? Hmm. . . maybe I should give it more thought.

Anyway, there are cases where a query will not give you the result your after. For example a query that doesn't ask for a "distinct" answer or a "min" or "max" might give you one result or might give you a set of a results. So the answers are hardly predictable, they are repeatable, but imagine when you are trying to fill one field and the results of the query is a set of values? That kind of thing happens all the time in new development. Maybe because the programmers are not as smart as they should be. (Maybe I'm speaking to much out of ignorence.)

There are ways of modelling a RL using a hierarchical type of system. Heck, even DB2 which is a relational database stores information in VSAM files. VSAM files aren't relational in nature, so how can they store a relational database? It's not very efficient to model a RL in a hierarchical database system, so we don't do it.

If something isn't efficient it's better not to do it.

Okay, I'm going to get a little fuzzy here: Perhaps I'm not being specific enough for the RL proponents and PHD's please forgive me and endulge me a little longer.

We have a bunch of programmers with limited skills. We have products that can offer a set of (a group of commands). Some products like COBOL (of course this isn't a database I'm just talking about a language product used), offer a lot of features and commands, but most business programs are only using about 12 commands from the COBOL langauge and a bunch of optional noise words. Then we have standards in the shop. Now when you enter a big shop you'll find out the standards are build not to build complex programs or solutions, but to build simple solutions to complex problems. That involves a lot of code. Yes a lot of code, but the basis and the building blocks are kept simple enough that almost any programmer can do maintainance.

Also make no mistake, almost all organizations have org charts and almost all processes have a hierarchical nature to them. So we end up coding some solution, but we don't code an esoteric (you need a PHD to understand it, and in theory the logic behind what the products we were trying to use should be good, etc) solution. You code an easy solution, something that anyone can pick up and correct later or change later.

So we have:
1. Ease of programming
2. Ease of maintainance.
3. Ease of readability
4. Speed.
5. Less maintainance or requirements of having a DBA (database) team deal with the process, because the DBA's would rather be at the local bar than help a programmer get their solution rolled out.
6. Built in data protection (okay without RL, that we don't have it, in most cases it's the responsibility of the programmer without an RL solution.) But the programmer should be responsible here and I still think the programmed solution is faster than the ERD process.
7. Query ability (RL has the edge here). But End Users are usually given all the query ability they need from the system screen design. Ad Hoc queries are a big selling point to management and the thing they fall in love with. Unfortunately for the Ad Hoc SQL ability they sink the entire IT solution or severely slow down the IT development by going to RL to wholeheartedly.
8. The ability for the end user to program a solution. (RL has the advantage here, if the users can understand SQL or the things they want can be implemented with a simple SQL statement.)

So all these features a person wants in a set of tools (the real toolset IT is straddled with) are NOT POSSIBLE with any current solution. You have to pick and choose the right technology for the job. COBOL and older systems have faired very well against the newer technology. All the "add on tools" that are supposed to save us time end up costing us more in the end it seems, at least where I work.

Heck we used to have 60 to 80 programmers out of a staff of about 110 IT people around here. Now we have perhaps a dozen programmers out of maybe 80 people and the rest are support staff? What are they supporting? They are supporting a bunch of extra technology layers, that don't really offer a return on the investment. Because in fact what we have at least where I work is:

1. Maintainance of a bunch of legacy code that is doing 95% of the work.
2. No enhancement of that code, very minimal enhancement.
3. Training for perhaps 80 people in new technology (like Oracle), spending millions of dollars and when it gets down to brass tacks, there is only 1 or 2 of us that are actually doing programming? There's efficiency.
4. Perhaps $500,000 worth of deliverable code for the outlay of $40 million.
5. Coding solutions in Oracle that take 2 years, when you could have rolled out the same system using older "legacy" style COBOL solutions that would do the same thing and provide a more maintainable solution in 6 months.
6. More and more "layers of solutions" each layer, network layer, out of state mainframe, presentation layer, Windows, Unix servers, etc. Gives us another possible failure point in the total delivery path of the information.

So I have to ask, although there's nobody here to ask in my organization (due to political realities), what is the point of going to an RL solution? Why go to RL when it costs so much more and basically we are now about 8 to 10 years behind where we should have been had we stayed with more traditional tools. Yeah we got ride of the 3270 terminals of the past, but now we're spending about $5,000 per (inflated) workstation price and buy and replace these machines offering all kinds of new features, but at a much higher expense and I'm not sure the 'bread and butter' applications are any better and often see the real tools we need delayed or not delivered at all. It's amazing.

As an IT shop "diversifies" into having more and more products (hardware and software) in their support and solution path, the layers of interaction and need for experts increase. Causing the fragmentation of the specialties in the shop. Now you have 2 experts in 50 fields instead of a bunch of people with the same expertise. All the solutions require a longer buerocratic chain to implement, so there are much longer delays, because the IT Assembly line is longer. Now "experts" sit around and wait a lot longer before their product can be moved to production, because we are waiting for a DBA to okay or change a spec, or waiting for some guy in another state to finish "surfing", yes surfing in the ocean, before putting an entry in a table, or waiting for some guy in another county to put in a simple change in LAN security, so we can get a task done.

So perhaps the problems I'm seeing are less related to RL theory and more related to how shops are implementing (and failing), and perhaps RL (theory) is getting a bum rap.

Thanks for the information. I still think there's a better way. Maybe someday I'll get greedy and publish a paper explaining how it could be done better. Maybe I'll get myself one of those shiney PHD's someday.

:)

Greg
(Programming from my little tower of Babel.)

Greg, When you talked about Genexus was the agency the UA of Michigan?

Yes it was.

I sat in on and saw the Genexus tool demo'd at UA, I knew from day one of that presentation it wouldn't work for us, but saying anything against the tool would have been pointless, since it was a political decision to bring it in.

Basically this was one of many wasteful uses of taxpayer dollars, in my opinion. Because, the end result was nothing of substance. Perhaps they made some headway in their development with the tool, but I can state with a fairly high (mathematical degree) of confidence, probably nothing has ever been modeled by that tool of any complexity in the real world. It's statistically impossible based on explainations given earlier in this thread. (Difference between static ERD and dynamic changing requirements.)

Genexus has a good premise because it states there is a problem. However Genexus has the wrong approach to the solution. Because it's trying to "patch" the problem. I thought anyone who knew the basic laws of programming (for instance I mentioned to other programmers in house anyone who understood "Warnier/Orr" programming charts) would understand that this tool wouldn't work. I stated to a co worker that anyone who understood Warnier/Orr diagrams would know this? Any programmer would know this tool couldn't work. Guess what, the author of the Warnier/Orr diagram was working on the tool and working for UA. I was shocked.

The person UA had hired working at fixing the Genexus tool was none other than Ken Orr himself. One of the authors of the "Warnier/Orr" book.

Shoot they named the logical diagramming method after him. I was speechless, to find out the author of the book was working on the tool or rather the fixing of the tool, so it would work. How can a lowely programmer like me, (in the eyes of my superiors) say anthing against someone like Ken Orr. Afterall it would be like having EB Codd himself working on a project in your company and you've found out he's working on a problem that he won't be able to solve. You'd just shut up and watch what happens. Well like so many other failed toolsets (whether by implimentation, ignorence or approach) this fell by the wayside. It's common for a large government entity or company to spend money on tools and not use them, so this isn't a rare occurance where I work.

IN THEORY: it was a great idea.
I liked in theory the idea and reasoning behind the tool, but saw that it wouldn't work in our situation, because Genexus is accurately approaching the "flaw" in Oracle and all SQL relational database "solutions", but it approaches it on the wrong level. In other words it's a patch above the flaw in the theory. I contend that a middleware patch above the flaw is like trying to build a house on a flawed foundation, which is kind of like the biblical saying, "don't build your house upon the sand". If the flaw with relational programming solutions is in the foundation, then until we fix the foundation, the houses built upon that will crumble. (The ERD's will not be accurate in a dynamic world.) Genexus was trying to sell it's solution as a type of "process" in other words it was really saying the process is ongoing and something you have to keep working at. In laymans terms, it's something you have to keep "redesigning". Now why do we have to keep redesigning the ERD? Well I contend we have to redesign the ERD because it's static and that's the flaw of it. Using a tool to constantly redesign the ERD, is just going along with the flaw in the RL theory itself, not solving the flaw.

So basically my opinion, is that the State of Michigan (this is my opinion, I cannot speak for the state of Michigan officially as I'm only an individual perhaps this could come under whistle blower laws, but who cares), was spending money on developing a tool that would never work. Kind of like an R&D budget for NASA, except we were paying for the development of a tool that would never work. These things are common, of course the little Genexus project wasn't a huge expense compared to other wastes of money that we've done, it's not like I'm blaming them for Michigan's balanced budget problems from our former Governor.

BTW: eventually I mentioned the flaws to one of the supervisors above me and they were totally surprised. . . as they had deluded themselves(were sold) into thinking Genexus would work. Eventually reality set in and that tool isn't used here and everyone associated with that tool, retired.

A high level of explaination would be middleware tools cannot work, because an algorithm cannot be put forth that would solve all mathematical proofs or all "story problems". An algorithm (the AI) in Genexus could never solve all ERD needs, because one mathematical equation cannot solve all future ERD "story problems". What Genexus AI would have to be able to do on a theorectical level is be able to solve all future mathematical problems with one proof, in order to work.

It's kind of like saying Genexus would be creating a form of AI life as in commander "Data" from Star Trek or perhaps the "learning computer inside the T1000 terminators head". It is statistically impossible. Although you could say that any computer language can solve all types of math problems, therefore any language would be a solution, in fact all computer languages would require a solution to be coded seperately inside them by a programmer or someone with math knowledge. I think the AI in Genexus would not be robust enough.

It's much the same way with Genexus, except, Genexus isn't a language, it's a piece of software that's proposing that it can "solve" the ERD problem with AI. I'll list the first two reasons it cannot work.

1. A mathematical solution to all problems cannot be found.
2. The nature of raw statistics of all permutations needed for data in screen and form design is to high a number for a correct number of permutational samples to be entered into a screen designer, etc. The middleware tool would have to see all variations of possible data as well as all variations of functional use, to get an idea how to behave and then be able to deduce a correct ERD. So even any "usage" of the screens by the test users or analysts that missed on type of "usage" since usage involves dynamic ways that users input data, not just the construct, would render a view of the actual "use" real world requirements of the ERD, to not be "true" to how the end screens would be used. That being the case.

1. The ERD definition would be based on false data, a subset of what was needed.
2. Even if the ERD could generate all the magical almost "divined" things that are brought into a design by a living DBA and analyst, for instance tables that are processing tables, it would not generate these correctly or have any way of knowing which processing tables were of use to the user community or rationale for their use.

Anyone with Warnier Orr knowledge or basic knowledge of programming should easily see this and you'd think the author of a book on third generation logic (Mr. Ken Orr) would know this.

I'm not saying Genexus hasn't accurately defined the problem with current SQL tools, just that they missed the solution.

Randy, did you work for Genexus? I might have met you briefly.

Greg

Yes it was.

I sat in on and saw the Genexus tool demo'd at UA, I knew from day one of that presentation it wouldn't work for us, but saying anything against the tool would have been pointless, since it was a political decision to bring it in.

Basically this was one of many wasteful uses of taxpayer dollars, in my opinion. Because, the end result was nothing of substance. Perhaps they made some headway in their development with the tool, but I can state with a fairly high (mathematical degree) of confidence, probably nothing has ever been modeled by that tool of any complexity in the real world. It's statistically impossible based on explainations given earlier in this thread. (Difference between static ERD and dynamic changing requirements.)

Genexus has a good premise because it states there is a problem. However Genexus has the wrong approach to the solution. Because it's trying to "patch" the problem. I thought anyone who knew the basic laws of programming (for instance I mentioned to other programmers in house anyone who understood "Warnier/Orr" programming charts) would understand that this tool wouldn't work. I stated to a co worker that anyone who understood Warnier/Orr diagrams would know this? Any programmer would know this tool couldn't work. Guess what, the author of the Warnier/Orr diagram was working on the tool and working for UA. I was shocked.

The person UA had hired working at fixing the Genexus tool was none other than Ken Orr himself. One of the authors of the "Warnier/Orr" book.

Shoot they named the logical diagramming method after him. I was speechless, to find out the author of the book was working on the tool or rather the fixing of the tool, so it would work. How can a lowely programmer like me, (in the eyes of my superiors) say anthing against someone like Ken Orr. Afterall it would be like having EB Codd himself working on a project in your company and you've found out he's working on a problem that he won't be able to solve. You'd just shut up and watch what happens. Well like so many other failed toolsets (whether by implimentation, ignorence or approach) this fell by the wayside. It's common for a large government entity or company to spend money on tools and not use them, so this isn't a rare occurance where I work.

IN THEORY: it was a great idea.
I liked in theory the idea and reasoning behind the tool, but saw that it wouldn't work in our situation, because Genexus is accurately approaching the "flaw" in Oracle and all SQL relational database "solutions", but it approaches it on the wrong level. In other words it's a patch above the flaw in the theory. I contend that a middleware patch above the flaw is like trying to build a house on a flawed foundation, which is kind of like the biblical saying, "don't build your house upon the sand". If the flaw with relational programming solutions is in the foundation, then until we fix the foundation, the houses built upon that will crumble. (The ERD's will not be accurate in a dynamic world.) Genexus was trying to sell it's solution as a type of "process" in other words it was really saying the process is ongoing and something you have to keep working at. In laymans terms, it's something you have to keep "redesigning". Now why do we have to keep redesigning the ERD? Well I contend we have to redesign the ERD because it's static and that's the flaw of it. Using a tool to constantly redesign the ERD, is just going along with the flaw in the RL theory itself, not solving the flaw.

So basically my opinion, is that the State of Michigan (this is my opinion, I cannot speak for the state of Michigan officially as I'm only an individual perhaps this could come under whistle blower laws, but who cares), was spending money on developing a tool that would never work. Kind of like an R&D budget for NASA, except we were paying for the development of a tool that would never work. These things are common, of course the little Genexus project wasn't a huge expense compared to other wastes of money that we've done, it's not like I'm blaming them for Michigan's balanced budget problems from our former Governor.

BTW: eventually I mentioned the flaws to one of the supervisors above me and they were totally surprised. . . as they had deluded themselves(were sold) into thinking Genexus would work. Eventually reality set in and that tool isn't used here and everyone associated with that tool, retired.

A high level of explaination would be middleware tools cannot work, because an algorithm cannot be put forth that would solve all mathematical proofs or all "story problems". An algorithm (the AI) in Genexus could never solve all ERD needs, because one mathematical equation cannot solve all future ERD "story problems". What Genexus AI would have to be able to do on a theorectical level is be able to solve all future mathematical problems with one proof, in order to work.

It's kind of like saying Genexus would be creating a form of AI life as in commander "Data" from Star Trek or perhaps the "learning computer inside the T1000 terminators head". It is statistically impossible. Although you could say that any computer language can solve all types of math problems, therefore any language would be a solution, in fact all computer languages would require a solution to be coded seperately inside them by a programmer or someone with math knowledge. I think the AI in Genexus would not be robust enough.

It's much the same way with Genexus, except, Genexus isn't a language, it's a piece of software that's proposing that it can "solve" the ERD problem with AI. I'll list the first two reasons it cannot work.

1. A mathematical solution to all problems cannot be found.
2. The nature of raw statistics of all permutations needed for data in screen and form design is to high a number for a correct number of permutational samples to be entered into a screen designer, etc. The middleware tool would have to see all variations of possible data as well as all variations of functional use, to get an idea how to behave and then be able to deduce a correct ERD. So even any "usage" of the screens by the test users or analysts that missed on type of "usage" since usage involves dynamic ways that users input data, not just the construct, would render a view of the actual "use" real world requirements of the ERD, to not be "true" to how the end screens would be used. That being the case.

1. The ERD definition would be based on false data, a subset of what was needed.
2. Even if the ERD could generate all the magical almost "divined" things that are brought into a design by a living DBA and analyst, for instance tables that are processing tables, it would not generate these correctly or have any way of knowing which processing tables were of use to the user community or rationale for their use.

Anyone with Warnier Orr knowledge or basic knowledge of programming should easily see this and you'd think the author of a book on third generation logic (Mr. Ken Orr) would know this.

I'm not saying Genexus hasn't accurately defined the problem with current SQL tools, just that they missed the solution.

Randy, did you work for Genexus? I might have met you briefly.

Greg

Yep that's me.

First the only use of GeneXus in that project was with database design and maintenance. And it worked exactly as it was suppose to. There was no GeneXus programs developed for that project, except some simple data entry screens to allow developers to enter and view test data.

The Business Logic was being programmed in a modified version of IPlanets Process Builder. Using generated EJBs from a generator created by the Integrated Projects staff. If you knew anything about GeneXus at all you would know that world wide there are over 4,500 customers using GeneXus with over 30,000 licenses and with 10s of thousands of applications having been built. The largest program developed and maintained in GeneXus has over 2,500 tables and over 25,000 objects that access those tables. That Application is a complete system developed for banking.

How can you even comment on that project? As far as know you had nothing to do with it, and you certainly didn't have any experience using GeneXus or any real understanding of what it can do. One thing is that the tool being developed which wasn’t GeneXus did work, one week after we started testing and preparing to build the production system the project was canceled with Compuware ® having 3 months left on their contract. The problem was; it was working and a bunch of people didn’t want it to.

There are two types of people who don't like GeneXus. DBAs as a rule don't because GeneXus forces them to have normalized databases and makes them use a proper naming convention. Not all DBAs hate it though some like what GeneXus does.

The other group is programmers because most programmers don't like the programming taken out of their hands. And with GeneXus you use a VB like language and some programmers think if your not programming in a real language like VC++, COBOL, etc your not really a programming.

Now GeneXus isn't for every type of program but when you are programming a Database Application it’s the best that I’ve used. Anyway I bet you that I can program quicker and with fewer errors than you can hand coding. In fact I can do it in less than half the time. Now maybe the fact that I have a lot of GeneXus experience might make it an un-even match, I mean I've worked for GeneXus Inc. as a consultant and tech support. So let me say this; any average person (Not even a programmer) can get GeneXus and learn it within one month and develop database applications faster than you can by hand.

It’s time to stop putting down CASE tools as a development option. GeneXus isn't the only CASE tool out there that isn't being considered just because it's a CASE tool. People seem to think that if the code isn't written by a programmer then it's junk; because no machine can figure out what needs to be coded.

The fact is that all programming have patterns. The companies that develop these CASE tools only need to apply the appropriate coding pattern for the problem, and you get code that has been proven to work for that problem. The best part about tools like GeneXus is that you’re not reinventing the wheel all the time and you have more time to deal with the requirements. Bad requirements by the way are why most project fail, not bad coding, with good requirements it’s easy to have good code. This by the way was what the Michigan project was all about, develop a system so that future development focused on the requirements and not the nuts and bolts of programming and when programming is necessary reuse code as much as possible. And had that project been finished instead of canceled then the UA of Michigan would have a state of the art development tool that would have been a huge step forward for State Government.

The real problem with that project is that not everyone knew what the goal was and instead of trying to find out they made up rumors. They kept saying that it would never work, but never really knew what it was. For instance GeneXus only did the database part and nothing else, but somehow you thought that GeneXus was the main tool being used. Like I said, just before the project was canceled we did get it to work, which was a strange time for the project to be canceled.

Other points you made:

1. You said that the agency paid hundred of thousands of dollars for GeneXus consultants. I was the only GeneXus consultant on the project the other consultants were Java developers building the extensions to the IP Process Builder and programming EJBs to be used in the UA solution being developed with the new tool. And GeneXus Inc. didn’t get anywhere near hundreds of thousands of dollars.


2. The reference you made to Warnier/Orr stuff, well guess what I currently work for Ken Orr at The Ken Orr Institute and the GeneXus programming model was developed based on Ken’s Data Structured Systems Development (DSSD) Methodology, which if I’m not considered an expert by now, I’m sure you would consider Ken the man who developed the methodology is. The only difference between DSSD programming model and GeneXus programming model is that GeneXus used Forms (Screens) to define the data structure instead of reports. This approach works just as well and has the added benefit of automatically creating the data entry screens at the same time as defining the required data structures.

3. Basically you got the impression what was being done was programming in GeneXus, when the programming was being done using a new tool being developed by the head of the IT department. Had we used GeneXus to develop UA’s new programs then it would have been done within the time I was there. That wasn’t what we were there to do.

4. You say that Ken was brought in to fix GeneXus. In fact Ken was brought in to help gather requirements so that when the new tool was done the programming staff would have the requirements to rewrite the UA applications using this new tool. He only gave advice to Bill on the development of the new development tool when Bill asked for it, and he certainly agreed with Bill’s approach. He surely wasn’t there to fix GeneXus as you stated; he couldn’t have since he was brought in before GeneXus was even being used there. He was the one that recommended that GeneXus be used to maintain the database and its metadata.

5. You say "A mathematical solution to all problems cannot be found." Probably not but a programmatic solution can solve programming problems. It might surprise you to know that solving the standard programming problems is relatively easy. When you program think of how many times you do the same thing over and over again the exact same way. Those are patterns and using those patterns to build programs automatically is very easy, it’s been done for a long time now. Look up books on template programming its’ been around since before the 80s. Even computer systems that can solve problems by trial and error have already been built, try looking up Evolutionary programming, though their not at true AI level; I believe they have found the root of what will truly become self learning systems. Think about how we solve any problem we run scenarios in our heads or remember a solution which problem closely models the problem we have and modify it to come up with the answer that most likely solves the problem. Saying it can’t be done only shows a closed mind.


For those of you who would like to try GeneXus please feel free to contact my former boss Mr. Dane Drotts mailto://dane@genexus.com at GeneXus Inc. I know that if you have an open mind and really explore what GeneXus can do you’ll be using it for all your Database application development.

Oh just to be on topic and all.

Putting all the Business Logic in the DBMS can be a huge undertaking. I’ve experienced a database where while trying to do everything in the DBMS someone added a wrong sequence of triggers and we ended up in having a cascading effect that brought the system down. Sometimes the Business logic is just too complicated, not that it can’t be done in the DBMS most DBMS have more than enough features to handle it, it’s just sometime it’s easier to handle it in code(for me anyway). As a Project Manager I wouldn’t allow for a rule that would force all the business logic to be on the DBMS, but there are times when putting it there is the best approach.

I can’t wait for the new version of MS SQL Server (Yukon) to be released with its added support for the .Net CLR; I’m guessing that we will see a move to put more in the DBMS for sure.

Thanks all
Randy Hester
The Ken Orr Institute

>> Saying it can’t be done only shows a closed mind.
----
1. I never said it cannot be done, only that the approach Genexus took was not optimal and probably not possible due to statisics and the nature of complex system design and redesign. For every example of a system you might show that worked I could find one that wouldn't work, meaning something is being missed by the approach, at least in my mind. But keep in mind I'm talking about a TRUE AI system that has a true foundation that can deliver on the promises of RL theory, not current relational technology.

This is kind of a theorectical discussion also and BTW I have a model that would solve (ALL BUSINESS ERD MODELS) and it would fit on ONE SHEET of paper. How's that for academic theory. I've only shown this model to one other programmer and he agrees that it would work. He's working on an AI NLP product as his second business hobby, making some progress, but NLP is another really big topic we need not get into here.

2. I still don't think you understand the point I'm making about an ERD being Static and real world requirements changing and being dynamic. Genexus is proposing it solves that with a process, but I'm saying the problem should not exist at all. (Cobb/Oracle and IBM missed something, that's what I'm saying and that is where the discussion starts getting into Academics and if you had say $1 Billion to hand me I might say more.)

3. Hmm. Amount of dollars spent on these different projects, well let's just say I had pretty reliable sources and as an employee your probably don't really know what your billing rates were by your company. People out there can do a FOIA to get figures on how much was spent on various budgets. I'm not sure how much detail is available legally, but it will show a lot of money was spent by the state and for high up political reasons there was a lot of consulting going on. Enough said.

4. I'll agree with you on most of the points about our shop being not an ideal example. There may be other shops that were able to use it. Most of this was due to our leadership (Bill) as you mentioned who was trying to use only part of the tool and develop the new tool.

5. Of course your version of the story is the tool worked and just was working when the project was cancelled. Maybe some progress was made, I certainly wasn't in a position to state how great it was near the end of the project, my comments were primarily geared toward the Genexus product and not the "new tool" Ken was creating to our specific needs.

6. I enjoyed your comments on Compuware (although for the most part they are completely wrong), well I cannot say what their motivation was regarding Genexus and the tool. But I can say that everyone I talked to at this shop who I've seen in their coding abilities and reputation based on work done here seemed to think that the tool would fail. Maybe it was bad rumors, but I fail to see the evil motivation of these people, since there were many other projects these people were busy with. They for the most part were not working on that specific Genexus redesign project solution.

7. Most of the problem with the project may have been due to "blue sky" thinking of the leader who brought Ken Orr in. I really cannot comment on his abilities, other than to state he's gone and really never got any return on investment for any of his wild ideas, just a lot of money spent and happy consultants.

8. Compuware, btw. . . since you're not here and I am here. Let me state that I have seen them work and get a LOT of projects done and these projects were complex and they brought in people with the appropriate programming expertise who did efficient friendly programming that actually worked. And they have been some of the best value on investment return comparing their billing rates to any other. This from "the rumors" . . . what I've heard through the "grape vine" here, a little bird told me. . . okay . . . I can't get into specifics because obviously it's something that just can't be done. Compuware was one of the best values we've every recieved from a consultant. I'd also have to give pretty high marks to Doug Clutter and Associates as they have done a lot of great complex design work up front. It's nice to see good consultants out there actually see projects through. And I'm not blaming you guys for the apparent failure of the earlier project (you state it worked and was killed by political reasons, hmm. . .maybe it was I can't verify that), there were as we know a lot of political things happening. Shoot a good consultant can be let go for the shirt they are wearing being the wrong color nowadays.

9. Genexus can code solutions inside it's own product. That is true (if it works as you know I haven't seen it work, but as you also stated I haven't seen it work lately because I didn't work on that project all the way through to completion/abandonment/whatever).

The thing is, performance issues and volumes of data by that tool were apparently not good enough for our particular application needs. Maybe we were not rightsizing the Genexus solution to the right projects. From what I've heard here (yeah maybe rumors) we were trying to do the BIG project with it, something that may have been a mistake.

This might be a rumor, but is what I've heard. Perhaps it was due to some kind of political internal smear that I'm not aware of. (BTW: I didn't try to kill the product while you guys were here and was not in a position to do anything to it, everything about that project was done by much bigger fish swimming in different waters than me.)

SPEED EFFICIENCY BENCHMARKS
If you could comment on the speed of the product compared to Oracle for many transactions. Saying 10,000 applications have been developed by companies means nothing if I don't know what type and what kind of benchmark performance they have. For example, hundreds of thousands of Microsoft Access applications have been developed and it has a niche market I'm sure as apparently Genexus does.

How many of us have been told Access could solve all our needs when it first came out and then when it came time to performance, well it didn't really deliver. But's it's okay for some small stuff.

Stating a raw statistic of how many applications exist means nothing if you don't know what type, size and complexity they are running against. (The Banking application sounds interesting, they should show a simular demo system to sell big companies on the product, if you want to really take over the world. . . my opinion.)

As you stated some things are better off not being in the RL because they are to complex. I'd say Genexus and most companies out there fail big time in their own marketing, because they simply don't show good examples and have some nice things out there for potential customers to see that actually work and do complex stuff.

If your talking about coding a basic 2 table system with a parent and detail with a screen designer like Genexus, well yes you can code that quicker than an Oracle programmer can. Customers out there need to see specific examples and benchmarks and talk to other customers who have used a product and see the TRUE expense, not just what a salesman is saying.

BTW: Hundreds of thousands of MS Access applications are build, but most of them cannot work with more than a dozen users. Suitable for small business. There are dozens of generalizations that are generally true about products, this does not mean the product is not suitable for some niche uses. But most are over-hyped. Now I'm sure that the "new tool" was overhyped by others inside our agency, and this was not the fault of Genexus or you(Randy) or Ken. But this does not change many of the facts I've brought up above.

Thanks for your comments Randy. It's been fun.
I hope I haven't been to general in my comments or not explained the main points I had in this thread which are really directed toward the foundation of a relational system being flawed in the ERD process itself.

Greg

An interesting take on this topic, not sure many will agree with BLL at the data level though (assuming I understood you correctly hehe).

I think Greg has some issues, could you go on and on and on any longer?

You make no sense.

Wow.

First of all, the original post had the identical black versus white dogmatism that I am always accused of having. It sounded like a post I would write. I enjoyed it and learned from it. Then came the repost. It was equally dogmatic, with the opposite viewpoint, and was also quite compelling.

I LOVE the Internet - where the titans clash over every single line that is drawn in the sand.

Many thanks. In the end, we are all winners in this kind of interchange.

From my current point of view, I best relate to the original article's point of view since my concern is getting the initial application right rather than being more flexible later, which I really don't think a truckload of code will provide me in the real world.

At any rate, this has been enjoyable. Thanks.

This greg character is not very bright. Essentially, because he likes to hear himself talk, he has only been critical of a technology that has and is being taught at every university in the world. MIT is wrong? Only Greg is right?

What you could do, is actually comment on the solution, which you obviously do not have.

But then again, you sound like you complain about everything in your life.

It's been a while since I visited this thread. I can see that nobody has solved the AI problem to replace DBA's doing an ERD yet. But many technocratic dreams still flow.

IF any of you knew the concept of an ERD and indeed the nature of program problems vs. pretending to be experts and charging hundreds of dollars an hour to give an ERD that will be obsolete within a year, then I'd have respect for you MIT and others.

But as one friend stated and put it so well, most people in IT are not interested in selling a solution, but a problem. So the users end up with a problem, and of course we offer to maintain and tweak it for them forever.

But a properly designed AI solution would not need programmers. Yet you are locked in your own past thinking and don't realize that. And maybe that's a good thing. It puts bread on the table. So who am I to rain on your parade.

Suffice it to say that permutations exist and no formula exists that can solve all problems. Since you haven't discovered a universal solving algorithm, you can't sell AI as anything more than hype.

A true AI is probably not possible and we can thank God for that. Although some will try to pass off their lame attempts at one and say this has intellegence.

Yes, MIT is wrong.