While reading this blog post I couldn't help but have a lot of ideas I needed to express. I will be formatting this post however in a way that the reader doesn't have to read both posts if they're short on time (though I would like it if you actually do read my friend's blog).
Should a product be tightly controlled to so that its quality is ensured? Could additional features and flexibilities be an obstacle for a product to fulfill its true value?
The issue here is with Java. Java is supposed to be the silver bullet of operating system-programming language decoupling.
Java is bytecode compiled. When on the actual target machine, it is probable that the JVM will do a JIT compilati0n. JIT is common among code that is bytecode compiled and is generally a reply to being less on performance on average than natively compiled code (C++ to x86 machine code for example). In some situations, JIT will produce machine code that is actually faster than code that had been remotely compiled and linked to encompass a vast array of machines.
So far so good. Java looks like a C++ killer, even on performance! A lot of people believed so as well. I am not sure however where things went wrong and Java scaled back to becoming yet another solution in the programmer's arsenal (or an additional item to the poor programmers confusion).
Almost with any program that has to do things that are not quite standard, the OS will allow you to do things that the general high level language doesn't have semantics for. Comes in JNI. A native interface for Java. It allows you to use Java to access OS specifics. Mind you, I didn't say use OS specifics from Java since once you're in that land, you've went out the boundaries of the design guidelines of Java. The write once, run anywhere gets broken.
Does this mean that Java is less or more portable. Is this flexibility akin to worsen Java's reputation?
I believe not. A tool must be open for use as the user wishes. While giving guidelines of recommended use for a tool, you should also think about it as such, not as a rule book.
To me, in conclusion as a reply to Tech Thoughts blog: In this contained context I elaborated in, I believe Java fulfills its promise as a cross platform tool (for where a JVM has been written at least) and allows the user to take a decision and break that advantage for the sake of a heartfelt use.
Sunday, June 27, 2010
Thursday, June 24, 2010
SQL Trees
Represeting tree structures in SQL is fun.
While direct modeling techniques in object oriented wisdom dictates the use of collections to references of children or references to parents, the story while doing some SQL could be quite different.
A naive implementation would have this shape: {id, parent_id}. parent_id maybe nullable or not. The non nullable approach would designate an id for the root virtual node, probably set as 0.
Another implementation would go the encapsulation route. The principle is extremely simple, but first here's the shape of a record: {id, lft, rgt}, where lft and rgt represent left and right respectively. How this record could represent relationships you may be keen to ask? The rules are very simple:
For all a and b we have the following rules:
* a.lft belongs to the interval ]b.lft, b.rgt[ <=> a is a child of b
* a.lft < b.rgt => a.rgt < b.rgt
The first rule defines the ancestry relationship.
The second rule defines validity of the data.
All operations on this table must respect these propositions.
The operation specification is actually very straightforward and intuitive once you accept the above rules and internalize them.
Insertion into a node is about pushing elements after that node to make space inside the node for the new one.
A data base may start with one single node as follows:
{0, 1, 2} ---remember the tuple representation mentioned above.
Inserting a new node under no other would result with:
{0, 1, 2}
{1, 3, 4}
Inserting another node under 0 would push the right property of node 0, in addition to the properties of all the following nodes (here only one with id=1)
{0, 1, 4}
{1, 5, 6}
{2, 2, 3}
This is of course not my ingenious invention. I read about it somewhere on the web, but ultimately the source I relied on to get the foundation concrete was Joe Celko. Look the name up, I recommend his books - condensed amounts of wisdom.
While direct modeling techniques in object oriented wisdom dictates the use of collections to references of children or references to parents, the story while doing some SQL could be quite different.
A naive implementation would have this shape: {id, parent_id}. parent_id maybe nullable or not. The non nullable approach would designate an id for the root virtual node, probably set as 0.
Another implementation would go the encapsulation route. The principle is extremely simple, but first here's the shape of a record: {id, lft, rgt}, where lft and rgt represent left and right respectively. How this record could represent relationships you may be keen to ask? The rules are very simple:
For all a and b we have the following rules:
* a.lft belongs to the interval ]b.lft, b.rgt[ <=> a is a child of b
* a.lft < b.rgt => a.rgt < b.rgt
The first rule defines the ancestry relationship.
The second rule defines validity of the data.
All operations on this table must respect these propositions.
The operation specification is actually very straightforward and intuitive once you accept the above rules and internalize them.
Insertion into a node is about pushing elements after that node to make space inside the node for the new one.
A data base may start with one single node as follows:
{0, 1, 2} ---remember the tuple representation mentioned above.
Inserting a new node under no other would result with:
{0, 1, 2}
{1, 3, 4}
Inserting another node under 0 would push the right property of node 0, in addition to the properties of all the following nodes (here only one with id=1)
{0, 1, 4}
{1, 5, 6}
{2, 2, 3}
This is of course not my ingenious invention. I read about it somewhere on the web, but ultimately the source I relied on to get the foundation concrete was Joe Celko. Look the name up, I recommend his books - condensed amounts of wisdom.
Subscribe to:
Posts (Atom)
Posts
