T has been ambiguous on telecom mergers. I don't have any links, but I remember him pandering to both the non-intervention angle, and the oligopolies=low-competition angle.
The future maintenance programmer will be most likely better educated
{snark} They can learn it all while riding in their flying car {/snark}
I see no evidence of an increase in such education over time. Statistically, programming is a dead-end career such that investing in high-end techniques may not pay off.
Moving rush hour into the air seems like it would be inviting chaos.
If they are for mass transportation, they'll probably have to be computer controlled. And they'd need some redundancy such they can land in a controlled manner if something goes wrong.
Darwen and Date tend to be pedantic and don't focus on things shops actually care about. They spend far more time on chalkboards than in the field.
Plus, SQL, or a variant of it, can be adjusted to fit most of their complaints. That would be more practical than entirely throwing out an established standard and starting over again from scratch.
Again, I have gripes about SQL also, but something typically has to be significantly better to replace a standard, not merely somewhat better. And the SQL standard can be adjusted and expanded as new actual lessons are learned.
Interesting. But they do seem like second-class citizens compared to "regular" columns in Maria-DB. It's extra syntax to use them. My approach would allow formality to be incrementally added without changing a column's "type" (mode?) from dynamic to static.
They also seem to require explicit type declarations. I prefer implied or WYSIWYG typing, a bit more like perl's typing model, even if it does complicate comparisons to some degree. (Different readers had diff opinions on how to handle dynamically-typed comparisons. I prefer a symbol next to the comparison operator, such as "#" for numeric: it's short and easy.)
Not really. Prolog is mostly a query-like language; I'm not defining a language. SQL, or at least some variant of it, is good enough; no need for users to relearn the entire wheel.
(I've proposed an alternative to SQL, but it's probably not significantly better enough to dethrone the de-facto standard: SQL, for most uses. But that's a different topic.)
Oh dear gods, you want dynamic schema because planning is hard and relational database normalization is too complicated for you. Nobody sees the value in your asinine idea because you're an idiot.
Sometimes planning is hard. I've been in many situations where the customer doesn't quite know what they want yet, and/or some trial-and-error is needed to settle on an optimum design. Think of it as a prototyping tool.
Have you memorized every domain and customer preference in the world?
and there's no distinction between a missing column and one that didn't exist, how does hashing work?
Same way as before. I don't see that as a practical stumbling block, but maybe you have a specific use-case in mind that would muck things up?
Informal categorisation and structuring has its place, but that's an entirely different beast to a relational database.
Indeed with regard to informal structuring: something easy to get going is often useful for prototyping. One can then lock down this tool incrementally as things settle (or migrate to a static RDBMS).
I've been in rather long debates about the definition of "relational database", and found no clear-cut "failure" to match. Language is subject to interpretation.
Anyhow, the idea is to produce a useful tool. It's formal category or definition is secondary to being useful.
Maybe with enough training and experience, one may be able to pull it off, but a future maintenance programmer may not be able to follow your technique well. It increases the hiring and training burden for your organization.
There are techniques that work better under ideal conditions, but ideal conditions are hard to come by.
I have to agree. You have to make it yourself. I've been trying to evangelize the idea of "dynamic relational" databases but nobody seems to see the value enough to care until they actually have something to try. You gotta make it first and THEN others will kick the tires to see if it piques their interest.
Slashdot Mirror
I remember ASCII pr0n, oh those wonderful @ signs!
"Your winnings, sir."
T has been ambiguous on telecom mergers. I don't have any links, but I remember him pandering to both the non-intervention angle, and the oligopolies=low-competition angle.
We'll have to wait and see.
Their new slogan: "Can we screw you now?"
640 bytes oughtta be enough for any shaky cat video. -Bill Catts
I imagine some Sheldon-like dude saying, "I refuse to play Mario unless he's physics-compliant. Screw cheapo incrementor variables!"
{snark} They can learn it all while riding in their flying car {/snark}
I see no evidence of an increase in such education over time. Statistically, programming is a dead-end career such that investing in high-end techniques may not pay off.
WhAt DoWnSiDe, PriCk!
Over the years, I've seen at least a dozen coffee research papers come out with a wide mix of good & bad news.
I average it all and conclude coffee is officially "meh" in terms of health.
If you can find a way to index blobs well, that could serve as a base kit on which to build specialized database-like tools.
Oh, Trumpware, cool!
If they are for mass transportation, they'll probably have to be computer controlled. And they'd need some redundancy such they can land in a controlled manner if something goes wrong.
Darwen and Date tend to be pedantic and don't focus on things shops actually care about. They spend far more time on chalkboards than in the field.
Plus, SQL, or a variant of it, can be adjusted to fit most of their complaints. That would be more practical than entirely throwing out an established standard and starting over again from scratch.
Again, I have gripes about SQL also, but something typically has to be significantly better to replace a standard, not merely somewhat better. And the SQL standard can be adjusted and expanded as new actual lessons are learned.
Dear Microsoft,
STFU.
Thank You.
I expect Moore's Law, or similar, will eventually make it practical to fit a PC in your pocket, giving Android and IOS more competition.
But it's hard to predict when that point will be reached. It may also require PC applications that are not such power hogs.
Interesting. But they do seem like second-class citizens compared to "regular" columns in Maria-DB. It's extra syntax to use them. My approach would allow formality to be incrementally added without changing a column's "type" (mode?) from dynamic to static.
They also seem to require explicit type declarations. I prefer implied or WYSIWYG typing, a bit more like perl's typing model, even if it does complicate comparisons to some degree. (Different readers had diff opinions on how to handle dynamically-typed comparisons. I prefer a symbol next to the comparison operator, such as "#" for numeric: it's short and easy.)
Not really. Prolog is mostly a query-like language; I'm not defining a language. SQL, or at least some variant of it, is good enough; no need for users to relearn the entire wheel.
(I've proposed an alternative to SQL, but it's probably not significantly better enough to dethrone the de-facto standard: SQL, for most uses. But that's a different topic.)
Sometimes planning is hard. I've been in many situations where the customer doesn't quite know what they want yet, and/or some trial-and-error is needed to settle on an optimum design. Think of it as a prototyping tool.
Have you memorized every domain and customer preference in the world?
Same way as before. I don't see that as a practical stumbling block, but maybe you have a specific use-case in mind that would muck things up?
Indeed with regard to informal structuring: something easy to get going is often useful for prototyping. One can then lock down this tool incrementally as things settle (or migrate to a static RDBMS).
I've been in rather long debates about the definition of "relational database", and found no clear-cut "failure" to match. Language is subject to interpretation.
Anyhow, the idea is to produce a useful tool. It's formal category or definition is secondary to being useful.
Do you mean unique keys or "tables"? Please clarify. An example of what you are trying to achieve or match in a practical sense would help.
Maybe with enough training and experience, one may be able to pull it off, but a future maintenance programmer may not be able to follow your technique well. It increases the hiring and training burden for your organization.
There are techniques that work better under ideal conditions, but ideal conditions are hard to come by.
Okay, the Snowflake Meme has been overused. Move on.
Here's one description, but it's kind of meandering:
http://wiki.c2.com/?DynamicRel...
I'm working on a shorter description that I plan to put on github.
I have to agree. You have to make it yourself. I've been trying to evangelize the idea of "dynamic relational" databases but nobody seems to see the value enough to care until they actually have something to try. You gotta make it first and THEN others will kick the tires to see if it piques their interest.
The gov't contracts out most of the work to private industry.
Personally, I'd like to see CA use the money for regular roads. The lane lines are all faded, for one.