Though I think that there is still room for such experiments and some projects could eventually become widely used (hopefully mine ;) — StrokeDB and Xi [which is on hold now])

I just thought it nice to use a clear phrase that every engineer, not just those in the agile/unit test crowd, can understand. Most people, even most programmers, don’t know that definition of legacy code. Everyone understands: “Tell me what you do. Show me where it says that. Prove that that is what happened.”

Also, unit tests are just one way to accomplish this.

And is that not an entirely appropriate stance for an engineer to take w/r/t to his own designs and creations? Is this not the basis for science?

IMHO, if you can’t prove your code works repeatedly without variance, then it doesn’t work or is ‘legacy code’ (i.e. an unknown variable).

Since testing database code is darned near impossible, or at least extremely annoying, difficult, time consuming, and expensive, it is extremely risky to put anything other than data and schema in the DB.

That is just one person’s definition (Michael Feathers). That is a lot like people who read Eric Evans’s Domain-Driven Design book and think his vocabulary for DDD is the only vocabulary that works. In a sense, his vocabulary is just a meta-model framework.

In a nutshell, your basic idea is CYA: “Tell me what you do. Show me where it says that. Prove that that is what happened.”

What do you consider “core logic”? In other words, what do you use stored procedures sparingly for?

I’m a little lost. Did bogardj just get you to convert your faith and regret your “stored procedures sparingly, for core logic only” position?

To be fair, it’s not my definition of legacy code, it’s MIchael Feathers’.

For some size perspective: I’m on a pretty small project right now, ~3 weeks long. It has 2000 LoC, roughly half in tests and half in the application.

Although it has several types that are persisted in the database, there are 0 (zero) lines of database access code. In fact, no project in this application references System.Data, the .NET data access assembly.

So even though my application relies on the database heavily for persistence, it doesn’t have a single line of SQL! All of our “data access code” is in NHibernate mapping files. The database is just a means of persistence for us, the heart of the application lies in the domain.

Our client assumes that the data is persisted in the database, but beyond that, they could care less. They care about the behavior of the system, not about the tables data is stored in.

Actually, the tool I use for programming PL/SQL, PL/SQL Developer by Allround Automations, has some assistance for simple automatic refactorings.
No, we don’t do enough unit testing, so in your definition we have a legacy system.

Maybe I work on simpler systems than you, but most of programs I make either store data in the database, or retrieve data from the database. So if I create unit tests that don’t touch the database, I test only 20% of the program.

@Lars Pohlmann

We have a developer here who comes from a Sybase background. Sybase uses the same T-SQL language as SQL Server. We had a bit of a hard time stopping him writing 5000 line procedures that did lots of different things based on flag parameters. Programming that way was of course a way to avoid the namespace problem. This might also explain that developers who develop against SQL Server or Sybase, are more violently opposed to using stored procedures than developers who use Oracle.

On the other hand, the argument that stored procs are bad, and the argument that SQL is bad because it’s hard to represent complex collections, are at odds with one another. Putting business logic in the DB is bad, yes. Going overboard with data rules can be problematic also. But let’s say you want to store and query a directed graph data structure. This is non trivial in standard SQL, but extending SQL via stored procs can make the querying code trivial.

The argument boils down to “I refuse to write reusable code so my code looks like spaghetti, therefore the language sucks.” Keep the domain code out of your database, sure, but don’t be afraid to add generic functions / procs to the database.

So two questions:

- How do you unit test your transactions/packages/types
- How do you refactor your transactions/packages/types

If either of these are manual or not done, you have a legacy code system.

I had a lot of these arguments with some Oracle DBAs at my last company. Eventually it came down to how easily the logic was to test. Since our domain behavior could be tested without ANY database up, our argument won out. 2000 unit tests against code executes in the same amount of time as 20 database tests. That means we could move much faster than the DBAs could.

Eventually, we moved a DBA to our team (instead of in their own group, which created an us vs. them mentality). They were then very helpful in seeing our modeling approach and making appropriate optimizations, partitioning, etc.

My point with the ‘assembly language’ remark wasn’t as much to say it’s a ‘low level language’, as to say that it’s an ‘arcane language with tons of idiosyncrasies and lots of legacy cruft that makes approaching SQL as a newbie/student very difficult and riddled with complications’