If you want to learn more, then I would suggest some project management books. I am a fan of Steve McConnell, and I like some of the stuff that the Agile Software folks have come up with. (Particularly their point that process is overhead, and the need for that overhead varies directly with the size of your team. Smaller teams should aim for less...)

Answering the questions despite the fact that I suspect that the answers will prove somewhat useless...

• Since we have business rules should the architecture of the system have middle-ware? The presence of business rules does not mean that you need officially separate middleware. But middleware may make sense depending on what you are doing. My inclination if you don't have experience, however, is to try to avoid middleware simply because it complicates your understanding of what is going on, and you are going to tend to confuse yourself a lot anyways.
• And if we will have middle-ware does the architecture have to be N-tiered? Well having a seperate middle-ware layer does suggest that you have an n-tiered system already.
• What languages should the middle-ware be written in? Whatever languages make sense for the team chosen, tools used, and protocols spoken. If you are using a proprietary pre-built piece of middleware, then you probably want to use whatever language is native to it. Otherwise you have more flexibility to use what you think will work best.
• Would the middle-ware contain the business objects? It can and often would.
• The original "developer" implemented the business rules in PL/SQL and triggers. Is this a bad thing? I wouldn't lean towards that choice. I like avoiding stored procedures because they tie you tightly to the specific database, create deployment complications, and PL/SQL is far from my favorite language. However they can offer significant performance benefits, and some people like factoring the logic that way.
• I feel that our "team" should only be responsible for the back-end and the middle-ware so do we need to be concerned about client/model views? Somewhat. You need to be aware of what the people using your stuff need from you, and you should be aware that many major hidden performance problems come because people building views repeatedly call back to the backend for pieces of data, when you could just call back for bulk data once. (Repeated queries for each item of data loses the automatic algorithm optimizations which are your reason to use a relational database - classic error!)
• Is the back-end basically a data warehouse and when combined with the middle-ware does this constitute a data mine? No. See an introduction to data mining to discover what it is.
• Should the business-objects contain the SQL to extract the data and manipulate it, then store that resulting data back to the database, or should the business objects call store procedures to do this? In a large system I would be inclined to factor the SQL out. In a smaller system you might do it either way above, or use any of a number of object/SQL mapping techniques.
• I am using terms correctly? Most of the time you aren't saying anything to indicate otherwise. That doesn't mean that you don't have some major misunderstandings which are simply not obvious from how little you have said.
• What is a Business Rule? Hmm, perhaps you don't know these terms so well. :-P Business rules are somewhat arbitrary restrictions that you have to meet for business reasons. Things like, "Only some people can see X" or "This calculation does not happen until the purchase is final." Generally they will turn out to be exactly the choice that makes your life as hard as possible. :-)
• What are client/model views? Pieces of a common design pattern known as Model-View-Controller.
• What is a data mine and a data ware house? A data warehouse is pretty much whatever people declare it to be. ;-) A data mine is a data warehouse with some sort of "intelligent learning" functionality in front of it to make it easier to get useful information without excessive human work.
• And last but not least what set of documents are typical for a small developement team that is developing a N-tiered system? Um, what does small mean to you? 2 people? 5 people? 20 people? It is all a matter of perspective. (See some of the agile software books for an idea of what documentation different sized groups have gotten away with in the past.)

If the decision is that Perl isn't right for the job, then you need to make your choice between grinning and bearing it, versus finding a job you would be happier with. My suggestion is that in this economy, a paycheck is worth a lot. My further suggestion is that it is worth exploring other languages, if only so that your advocacy of the ones that you like can be more grounded in experience than fear of the unknown. (And who knows, you might discover things you like about languages you feared learning about!)

I like avoiding stored procedures because they tie you tightly to the specific database, create deployment complications, and PL/SQL is far from my favorite language.

Stored procedures are a great way to separate the logical model (which is how the programs look at the data) and the physical model (which is how the data is laid out in tables). Stored procedures greatly increase the flexibility of your solution; they make scaling much easier; they allow you to much easier enhance your code.

I used to work for a company that wrote a large financial software package. Millions of lines of code, close to a thousand binaries, and about 1500 tables. Parts of code touched the tables directly, better designed parts used stored procedures to access the data. Guess which parts were a nightmare to modify?

Abigail

I'm sure that you can make it work, and make it work well. Also if the system has been factored in a given way, maintaining the factoring is typically going to work far better than degrading it.

I'm also sure that my preferences are shaped by an experience with some stored procedures which were very poorly written, which contrasted nicely with cases where the same logic had been moved into an application layer and then was organized there fairly cleanly.

And I would like to point out that when I said, "I wouldn't lean that way..." I meant that to be truly understood as a personal preference which others disagree with, and which I might choose either way on in practice. You demonstrated nicely that others do disagree, and confirmed at least one of the grounds on which they disagree. (The performance benefit from being able to rethink your database design.)

Plus finally I would like to note that the choice of which way to make this decision is not as important as who you have doing the work. Competent people can make either decision work, incompetent people (or even competent people with the wrong background or pressures) can make either fail.

Errr ... uuhhh ... mmmm ... no. I usually hate to disagree with Abigail (I or II) but stored procs are just another language on another platform ... they are no better (nor worse) than other languages and they can increase as well as decrease the flexibility of your solution. I've seen some stored procs that can be pretty much declared disaster areas (sometimes an indication of a pretty lousy schema underneath). It really all depends on the the talents of the individuals involved.

-derby

Now I am confused. If I implement my business rules in stored procedures
in my database, doesn't that mean my middle-tier is in my backend?
Isn't tyipcal to have your business rules in the middle-tier?

According to C.J. Date in What Not How, ideally all business rules would be expressed by declared database constraints rather than by stored procedures, "Declarative is better than procedural!" But given a choice between stored procedures and enforcing the rules over and over in each application that uses the database (and then probably missing some cases), the stored procedures seem like a win.

First off, I agree. Having a decent set of stored procs can really simplify migration and changing situations, a stored proc might even return results from a totally different DB than the one the user is connected to. But I was wondering about one thing, I am a Sybase user, iirc you are as well. Ive noticed that a heavy use of stored procs is favoured by Sybase users. Since I've not had much exposure to other DB's I cant really say, but I have noticed that it seems users of other DB's tend not to go that way. Any thoughts from your point of view?


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}

Since we have business rules should the architecture of the system have middle-ware?

No, although it's not uncommon to have middle-ware. But whether or not to have middle-ware depends on more than just having business rules.

And if we will have middle-ware does the architecture have to be N-tiered?

Strange question. Are you considering to have just middle-ware, without a front-end or a back-end? Otherwise, if you have front-end, middle-ware and back-end, you have a 3-tier architecture.

What languages should the middle-ware be written in?

That depends on many things, but not the fact it's middle-ware. It depends mainly on your problem set, and your programmer set. Another factor will be possible third party software.

Would the middle-ware contain the business objects?

If you have business objects, and you're going to implement business rules in your middle-ware, then that would be the logical place for them. But if you don't have business objects, the answer would be no.

The original "developer" implemented the business rules in PL/SQL and triggers. Is this a bad thing?

Perhaps. Perhaps not. It depends what the business rules are. If it's a system to control traffic lights, PL/SQL might not be the right choice. For some financial applications, it might be a right choice.

I feel that our "team" should only be responsible for the back-end and the middle-ware so do we need to be concerned about client/model views?

I'd look for better programmers if my programemrs had such a narrow view. Even if you focus on the back-end, you still need to interface with the middle-ware - after all, the back-end isn't a goal on its own. The end goal is always the total product, and you should never ever forget that.

I assume you mean "client/server model" in you last sentence. You need to be concernced about a "client/server model" if that's the interface you are going to use between the middle-ware and the back-end. If you are going to use a different model, get concerned about that model.

Should the business-objects contain the SQL to extract the data and manipulate it, then store that resulting data back to the database, or should the business objects call store procedures to do this?

Stored procedures will give you some great advantages - it separates the logical view of the data (which your programs have), and the physical layout in the tables. I prefer my code to not touch the tables directly. It could also give you some performance advantages, as stored procedures are compiled only once - and only need to be recompiled if the database goes down, or when they are reloaded.

I am using terms correctly?

You sound like you are a manager who just came out of a meeting, having heard a ton of new buzzwords.

How can we know you used the terms correctly? You used a lot of terms, but you don't say what you mean by them. Perhaps you mean by "business rules" and "middle-ware" something totally differnent than the rest of world does.

And of course how can I sell my boss on using Perl for parts of this system?

What makes you think Perl would be a good choice anyway? If your team consists of mostly people knowing Java and C++, and nothing else, Perl doesn't seem like a good choice to me. If your boss thinks it's far more difficult to hire new, capable, Perl programmers than capable Java programmers, Java might be a better choice. If there are a lot of ready made C libraries available that will do most of the work, C might be the better choice.

If you have to ask here how to get your boss to approve the use of Perl, it seems to me that you can't think of enough reasons yourself. And if you can't think of enough reasons to go for Perl, Perl might not be the right choice.

Abigail

D'oh! Thanks for catching that. I meant model/view not client/model views.

"Business rules" are rules that aren't required for any technical reason, but are needed to fit in with how your buisness operates. For instance, as far as SQL is concerned, it makes perfect sense to have an order placed without a customer, but that doesn't make any sense to a retail store that runs this database.

The original "developer" implemented the business rules in PL/SQL and triggers. Is this a bad thing?

It depends (:

What languages should the middle-ware be written in?

A turing-complete one would be good (: Again, it all depends.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Or should I be more open minded about these platforms?