![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
DBA, DBA, make me a field....
Jan. 9th, 2007 10:33 pmPost prompts gleaned from this poll. Feel free to ask something if you haven't.
I spent quite a while working on my thesis. It started, ostensibly, in 2004. I was taking a class in database theory (something beyond database usage) and I wanted to define a better way of learning the concepts. However, I was busy NOT learning them, myself.
You see, in their wisdom, my school decided that I'd done so much work with databases that the basic class would have bored me.
And, this is probably true. I have been working with database systems and structures since 1983. And, yet....
I have always felt that experiential knowledge, while useful, is insufficient to real learning. All my work experience may be good, but if I never had a reason to use **THAT** function, I will have never seen it. What you can experience on your own is colored significantly by other experiences, issues, and opportunities. You can never hope to find the "one path to enlightment" when you are are not aware that you are standing on an infinite plane, and the path you define is only one of many you could have discovered, and even then may not reach the goal you think you are after.
This is not to say that experience should be avoided, as this brings about a kind of learning indistinguishable from faith. Even so, faith properly placed can guide experiences in a constructive way, where every new event adds to the whole. This guidance is critical to learning, and why I require it as part of any attempt to make real headway in a subject. Not that headway is a requirement! Learning can happen independent of any real objective, of course.
Some that are walking a spiral inward seek to define learning as goal oriented, and when they walk around what they believe is their goal they approach it slowly, claiming every step either leads them inward or stands contrary to the path. This is, of course, a faulty vision of the walk, as even though the path along the spiral reaches the goal, so does the path straight inwards, and so does the path outwards. Why? Because enlightment is inevitable, and the goal is in all directions. How long you postpone it is up to you, after a fashion, but even a dedicated attempt to get there may take more time than you expect, as your straight line could be a spiral on the edges of opportunity you do not see.
Learning, then, is the accumulation of enlightment in all forms, those you have discovered and those from others, of finding the opportunities you seek while learning of those you may have failed to see. Trancendence is not a thing to be grasped, but a state in which to live. There is no magic moment of luminescence, but merely differences between yourself and your background. In the dark, a candle shines, but in the day the candle is insufficient. We learn by experiencing not only our own opportunities, but those of others, who learn by sharing them, bringing brightness to the darkness. There is enlightenment in information architecture, in the curve of a flower petal, in the breath of a baby, in the sound of a violin, and infrequently in the preparation for war. And, of course, in many other things as well.
The trick is being open to them, and not claiming one path is better than all others.
In an infinite universe, there are multiple paths that learning can take. Experience can get you places, but may cause you to choose poorly as you are confronted with infinite opportunity and limited wisdom on which to guide your future. Thus, you cannot hope to align yourself with something which has no direction, no vector, no motion. Instead, you must give the universe an appearance motion with your vision, which arises out of your gathered state of awareness. The universe begins within.
And, within myself, at that moment, was an extreme lack of understanding of about 80% of database design.
I spent quite a while learning SQL on my own, studying the concept of Entity-Relation diagrams, correlating data structures and how pieces of them interacted with others. In a sense, then, a database is a universe of enlightenment; it is an accumulation of awareness and understanding that can expand forever, but is only useful when interrelations are encouraged that reveal underlying mechanisms and concepts. There is no RIGHT way to view a database, but failing to view it at all is most decidedly wrong. And, what database one uses can directly impact the results of this observation, providing good or bad guidance.
I got some of the worst guidance possible from MySQL. At the time it didn't have stored procedure support (something I was trying to learn) outside of development versions that implemented inconsistently. JDBC was problematic, though it was officially supported, and much of the metadata requirement was woefully inadequate. I understand this has improved, but at the time it was a problem. Even worse, in default mode MySQL isn't transaction safe, making it possible to update something, try to read it, and get older data. And heaven help you if you try to figure out if NULL is NULL or NOTNULL, as it is implemented in ways that make for a headache or two....
Oracle was much better, but it took quite a while to get access to the Oracle server on campus, and I had a habit of writing code that failed to close connections properly (I neglected the 'finally' instruction in my try/catch blocks). To Oracle, such an act is poison, as version 8i would accumulate these open connections until it crashed. Almost always on a Friday after 6pm. ::sigh::
PostGreSQL was nice, but the server I got to use wouldn't allow remote connectivity, so I had to be on campus or using ssh onto the server so my tests were local. And that meant I had to export all my visualizations to my home computer bit-by-bit instead of using local Java to display the data. Very time-consuming, and ugly. It did reveal a bug in Java, though, and I got to report it! Still a bug, but at least they know about it.
So, in short -- Oracle, PostGreSQL good. MySQL bad (for now). Did I enlighten you? Or, at least light a match in the darkness?
I spent quite a while working on my thesis. It started, ostensibly, in 2004. I was taking a class in database theory (something beyond database usage) and I wanted to define a better way of learning the concepts. However, I was busy NOT learning them, myself.
You see, in their wisdom, my school decided that I'd done so much work with databases that the basic class would have bored me.
And, this is probably true. I have been working with database systems and structures since 1983. And, yet....
I have always felt that experiential knowledge, while useful, is insufficient to real learning. All my work experience may be good, but if I never had a reason to use **THAT** function, I will have never seen it. What you can experience on your own is colored significantly by other experiences, issues, and opportunities. You can never hope to find the "one path to enlightment" when you are are not aware that you are standing on an infinite plane, and the path you define is only one of many you could have discovered, and even then may not reach the goal you think you are after.
This is not to say that experience should be avoided, as this brings about a kind of learning indistinguishable from faith. Even so, faith properly placed can guide experiences in a constructive way, where every new event adds to the whole. This guidance is critical to learning, and why I require it as part of any attempt to make real headway in a subject. Not that headway is a requirement! Learning can happen independent of any real objective, of course.
Some that are walking a spiral inward seek to define learning as goal oriented, and when they walk around what they believe is their goal they approach it slowly, claiming every step either leads them inward or stands contrary to the path. This is, of course, a faulty vision of the walk, as even though the path along the spiral reaches the goal, so does the path straight inwards, and so does the path outwards. Why? Because enlightment is inevitable, and the goal is in all directions. How long you postpone it is up to you, after a fashion, but even a dedicated attempt to get there may take more time than you expect, as your straight line could be a spiral on the edges of opportunity you do not see.
Learning, then, is the accumulation of enlightment in all forms, those you have discovered and those from others, of finding the opportunities you seek while learning of those you may have failed to see. Trancendence is not a thing to be grasped, but a state in which to live. There is no magic moment of luminescence, but merely differences between yourself and your background. In the dark, a candle shines, but in the day the candle is insufficient. We learn by experiencing not only our own opportunities, but those of others, who learn by sharing them, bringing brightness to the darkness. There is enlightenment in information architecture, in the curve of a flower petal, in the breath of a baby, in the sound of a violin, and infrequently in the preparation for war. And, of course, in many other things as well.
The trick is being open to them, and not claiming one path is better than all others.
In an infinite universe, there are multiple paths that learning can take. Experience can get you places, but may cause you to choose poorly as you are confronted with infinite opportunity and limited wisdom on which to guide your future. Thus, you cannot hope to align yourself with something which has no direction, no vector, no motion. Instead, you must give the universe an appearance motion with your vision, which arises out of your gathered state of awareness. The universe begins within.
And, within myself, at that moment, was an extreme lack of understanding of about 80% of database design.
I spent quite a while learning SQL on my own, studying the concept of Entity-Relation diagrams, correlating data structures and how pieces of them interacted with others. In a sense, then, a database is a universe of enlightenment; it is an accumulation of awareness and understanding that can expand forever, but is only useful when interrelations are encouraged that reveal underlying mechanisms and concepts. There is no RIGHT way to view a database, but failing to view it at all is most decidedly wrong. And, what database one uses can directly impact the results of this observation, providing good or bad guidance.
I got some of the worst guidance possible from MySQL. At the time it didn't have stored procedure support (something I was trying to learn) outside of development versions that implemented inconsistently. JDBC was problematic, though it was officially supported, and much of the metadata requirement was woefully inadequate. I understand this has improved, but at the time it was a problem. Even worse, in default mode MySQL isn't transaction safe, making it possible to update something, try to read it, and get older data. And heaven help you if you try to figure out if NULL is NULL or NOTNULL, as it is implemented in ways that make for a headache or two....
Oracle was much better, but it took quite a while to get access to the Oracle server on campus, and I had a habit of writing code that failed to close connections properly (I neglected the 'finally' instruction in my try/catch blocks). To Oracle, such an act is poison, as version 8i would accumulate these open connections until it crashed. Almost always on a Friday after 6pm. ::sigh::
PostGreSQL was nice, but the server I got to use wouldn't allow remote connectivity, so I had to be on campus or using ssh onto the server so my tests were local. And that meant I had to export all my visualizations to my home computer bit-by-bit instead of using local Java to display the data. Very time-consuming, and ugly. It did reveal a bug in Java, though, and I got to report it! Still a bug, but at least they know about it.
So, in short -- Oracle, PostGreSQL good. MySQL bad (for now). Did I enlighten you? Or, at least light a match in the darkness?
