This could very easily become a religious war with both sides dreaming up examples of where their preferred technology out-performs the other. For example, one could easily come up with a more complex example that in an OO world will return the required information in very short order, even with interpreted Jade code, but take magnitudes of time longer in a relational SQL select statement world. A much less complex example could be as follows:
Suppose you have a table of purchase orders, keyed by the purchase order ID field as per your previous example. You now want to know how many purchases customer #1234 has made so you'd write something like the following, assuming you have the customer number inserted as custId in the "PurchaseOrder" table:
select count(*) from PurchaseOrder where custId = 1234
As you add more entries to the PurchaseOrder table, this will of course naturally take increasingly longer to execute as it has an increasing number of rows in the table to traverse when processing the select statement. Now, the semi-equivalent JADE code:
cust.allPurchases.size
Time to execute is not affected by how many purchase order instances there are.
As I said at the beginning, this could easily become a religious war so why not simply agree that there are situations where either technology will easily outperform the other and use whichever technology suits the requirements of the development at hand.
eg: There are situations where it is appropriate and right to choose and use tools other than Jade to develop your solution.
Given complex real world requirements to solve in an application, at this point in time I would much rather use Jade as my development tool of choice to develop that application as my development time is much faster than it was with the other technologies I used to use. If simple queries like the ones you have used as examples take a little longer to process then that is a price I am more than willing to pay for the benefit of faster development time. I can of course utilise some of the time I saved developing the application to optimise any common query requirements of the end users as appropriate to reduce this time.
Looking at the 6.1 road map, the new Relational Population Service seems to allow us to have the best of both worlds. Develop the application faster and still have the option of running adhoc SQL queries over an appropriately populated relational database.
Hope that helps,
Pat.
Hi Pat
Yes, I agree this could become a religious war between both sides. And obviously, that's not what these newsgroups are for. You will have noticed that these groups are populated (mostly) by Jade developers (which I am), and I thought it useful to have an alternative perspective on things.
The example you cited is obviously correct, but Jade is making the classic computer science space/time trade-off in being able to do this. It's effectively storing the results of queries. To counter this example, if I added an index to my relational PurchaseOrder table over the Customer ID column, the number of rows would have to grow *substantially* large before the query was likely to be considered slow. To me, this is one of the big advantages of relational databases - the ability to tune deployed systems. Whereas in Jade, I have to go back to the developer who then has to add a new collection (and then modify the code to use it) in order to tune the performance.
I really also take issue with your claim that apps get built faster in Jade. Having seen both sides, there are certainly some things that are quicker in Jade, but on the whole, given the amount of stuff you have to build yourself in Jade, as opposed to a whole world of available components, not to mention advice available (ever tried solving a Jade problem by googling it?, ever looked in a bookshelf for books on Jade?) I think, on the whole, I can produce better systems that better meet customer expectations in mainstream technologies.
So, I've said my piece. I'll shut up for now
