The pop culture definition may be overgeneralizing, but not by much. Looking at markets, there really is a lot of copy and paste and mutate in the way business models and such are formed. People think they know how they run a business, but most of the time it's pretty mindlessly sticking to a formula.
When you really look at it, people don't think very much at all. We almost inevitably copy how someone else did something and tweaked it a bit. Even if you carefully work something out using mathematical reasoning, you're mostly reapplying other people's work.
The "DNA" is still there, it's just in the form of ideas and processes.
"I believe in micro-evolution but not macro-evolution"
"I believe in centimetres, but not metres"
More like, "So you claim I'm standing in my "house," and that it's 20 meters high. Well, if I squint I can see a centimeter of housey-stuff here, and a centimeter of housey-stuff there, and I do in fact live here, but there's no evidence of this large structure you call a "house"!"
I've been on LinkedIn since 2006. It's really gone downhill.
Networking is a fine thing to do and makes sense, at least given that HR departments don't actually do their job. Unfortunately, there is a large contingent of markety types who seem to think that networking and motivational crap can completely take the place of actually doing work. And they are dominating LinkedIn right now.
If, perchance, they actually listened to your argument, I'd say "yes, next let's move on to patenting business models" except I'd be more worried about some equally unlikely shit happening.
Obviously for the victim or his family it would be terrible, but once the scandal broke that the explosives had been planted on him by operatives there would no longer be any armed thugs in airports around the world, and we'd all be treated with a little more respect.
Thanks for mentioning that; I absolutely didn't know about the editions feature.
It highlights, though, a big issue with Oracle: they have so many complicated features that their transactional model is incomprehensible. There's the standard commit, rollback and savepoints, then you have flashback, and you have the undo, and now you have editions.
(I probably have some details wrong, but in my defense I'm more of a software guy than a DBA, and I'm just not that interested in learning all things Oracle. Great system, I just wish it would get out of my way.)
From looking at the docs you linked to, I can see how it would be incredibly useful. Editions essentially allow the DBMS to allow multiple versions of the database. That's not what transactional DDL is though, and editions don't replace that functionality.
I don't think Oracle is going to offer that feature, incidentally, because very few of their customers actually want it. You only need transactional DDL is when you need to modify your schema dynamically. (And if you think you can _correctly_ modify a schema dynamically without it, you don't understand concurrency.) In a typical Oracle setup you're encoding business logic in the schema and you virtually never need or even want to do that. Your database not only represents but literally is a set of legal and financial obligations. You're just not going to want to create new rules on the fly or, worse, have those things disappear without a trace.
I would have thought even after that, they'd still be curious as to how you put the dress on without it tearing...
Re:There is already a perfectly good free DBMS
on
Monty Wants To Save MySQL
·
· Score: 4, Informative
Can you elaborate on the 'correct' with emphasis?
Google says that both postgresql and mysql get hits from 'incorrect results'. Are you stating that mysql's bugs have gone unfixed while postgre's have not? Or what?
For fairness, I'm going by MySQL version 5.5, the development version.
There are multiple "SQL Modes" that can alter correctness, source, but by default the DBMS doesn't try to validate input. It's pretty confusing what mode does what, and I don't care enough to figure it out, but MySQL's approach has always been Do What I Think You Mean, and if they set the new version to be ANSI compliant by default it'd break all the existing sites built on it.
(I'm claiming this qualifies as "not being correct" by virtue of the Information Principle. Granted, SQL itself violates it in many ways, but MySQL proved that you can do worse than SQL.)
PostgreSQL has a far more correct transaction model. In some ways, they're actually better than Oracle. (In Oracle, a DDL statement will start a new transaction, whereas PostgreSQL wraps DDL into a transaction.) For starters, there aren't multiple "storage engines" per table with different transactional behaviors. source, sort of.
Also, PostgreSQL, to my knowledge, correctly validates input. It's kind of hard to cite a source for this since there's just no FAQ entry "Q. How do I configure PostgreSQL to silently corrupt my data? A. You can't." But by the same token, they don't have any long-standing terrible design decisions that they have to maintain compatibility with.
Sun bought MySQL so that Oracle can buy Sun and then the idea is to kill MySQL without running into any legal issues. If Oracle was to buy MySQL directly, then it is a no-no and it is highly the US government would let that happen.
Except for the small issue that MySQL is not a competitor to Oracle. PostgreSQL might be biting at their ankles. People who don't do this stuff for a living don't understand how important the M in DBMS is.
Honestly, how is it acceptable for the police to lock someone in jail simply for refusing to obey a command?
It's less unacceptable than us, as voters, being disenfranchised because the laws our representatives wrote were ignored because the executive branch had no authority.
Yeah, FAT looked like a clever system when I was just learning and had never heard of a B+ tree.
From what I recall (FAT32 and exFAT both add structures and I'm only somewhat familiar with FAT32) FAT basically has a header (fixed at block 0, terrible for flash media) with a fixed list of root directory entries and the eponymous file allocation table. The FAT itself is just a list of every cluster in the media; each entry is either a link to the next block or an indicator if it's bad. Directories are allocated like files; they are a straight list of entries.
And that's *it*. Simplicity is fine, but, as common experience shows, it just isn't good enough.
FAT looks like someone's half-baked science project. FAT32 and exFAT (aka FAT64) just take the same mistakes and repeat them.
The fact that FAT32 is widely available is irrelevant; everyone will still have to install drivers.
So, yes, there's a demand for a simple (needing little CPU and RAM) filesystem. There's even an argument to be made that it should honor the same overall contracts that FAT does so that device manufacturers don't have to put lots of extra logic in. But it does *not* need to be the spawn of FAT.
Yeah, in European society, you've become so civilized and regulated that you're not really moral agents any more. How can a robot (the etymology is a treat) really be considered to commit a crime? It must simply be malfunctioning and be put in an attitude readjustment center.
Re:Dynamic Relational: change it, DON'T toss it
on
The NoSQL Ecosystem
·
· Score: 1
May I ask for a scenario demonstrating "poorly"? It can still do joins, aggregation, and indexing just like any other RDBMS. It's not clear to me what you think is missing.
Any kind of integrity constraints, even as simple as including enforcing types. You can kind of sort of do it with triggers but, like I said, you're reimplementing the DBMS. I speak from having _extensively_ implementing an EAV system and totally engineering myself into a corner with it.
The only thing you really gain is transactional support for creating / altering tables, but a good DBMS like PostgreSQL can do that anyway.
Depends on the project. Sometimes nimbleness is a strategic advantage, such as prototyping or ad-hoc analysis.
Those are phases of development, not types of projects. And nimbleness sucks when someone else has to figure out what you're doing, i.e. the maintenance phase.
But I too have also formed a draft query language influenced from IBM's BS2.
Hey, good luck with it! I didn't have any PDFs up there, there are couple now. The section I'm working on is fairly basic mostly because a lot of people think they understand relational theory because they've used SQL DBMSs. Most of the actual language comes out in the next part.
Re:Dynamic Relational: change it, DON'T toss it
on
The NoSQL Ecosystem
·
· Score: 4, Interesting
However, the "rigid schema" claim bothers me. RDBMS can be built that have a very dynamic flavor to them. For example, treat each row as a map (associative array).
You described an entity attribute value model, which winds up reinventing half the DBMS, poorly. Don't worry, *everyone* does one once until they realize it's a bad idea.
Constraints, such as "required" or "number" can incrementally be added as the schema becomes solidified.
A "rigid" schema is preventing a ton of totally redundant code being written on the app side. All those constraints wind up in the schema because your UI designer doesn't want to consider that Mary might have 5 addresses or 6 mothers or work 7 jobs simultaneously. And your UI tester doesn't want to test an exploding combinatorial number of possibilities.
I'd like to see, however, a decent type system, proper logical / physical separation, etc.
Maybe also overhaul or enhance SQL. It's a bit long in the tooth.
That works, until the user is a bigger jerk than you are. I worked for a fairly senior enlisted man who was pretty bad about computer security. He related to me a story about how some system he needed to use generated a password for him, but it was totally random and he couldn't remember it.
There was no option, whatsoever, to generate any kind of "friendly" password or to make it memorable. So his solution was to call the help desk and to insist upon getting a password he could remember. The female tech started out, much as you suggest, by explaining that there was no way she would do that. He responded with 30-odd years of experience in yelling at people, which brought her to tears, and she wound up resetting the password until she got one he could remember.
The guy's pretty sharp about most things; he did a lot to straighten up record-keeping which definitely improved our operations, and probably did a lot to improve security overall. But he's that deadly combination of lousy at managing passwords and extremely effective at getting his way. So any plan that is "yell at people" has to account for the fact that the most critical individuals are liable to yell back.
Slashdot Mirror
The pop culture definition may be overgeneralizing, but not by much. Looking at markets, there really is a lot of copy and paste and mutate in the way business models and such are formed. People think they know how they run a business, but most of the time it's pretty mindlessly sticking to a formula.
When you really look at it, people don't think very much at all. We almost inevitably copy how someone else did something and tweaked it a bit. Even if you carefully work something out using mathematical reasoning, you're mostly reapplying other people's work.
The "DNA" is still there, it's just in the form of ideas and processes.
"I believe in micro-evolution but not macro-evolution"
"I believe in centimetres, but not metres"
More like, "So you claim I'm standing in my "house," and that it's 20 meters high. Well, if I squint I can see a centimeter of housey-stuff here, and a centimeter of housey-stuff there, and I do in fact live here, but there's no evidence of this large structure you call a "house"!"
Wow, just because creationists are wrong doesn't mean you have to be so blatant about suppressing them.
They happen to be right on this point: proof of natural selection is not proof of evolution as a whole. The Doonesbury comic got that wrong.
If computers could magically detect bullshit the way this journalist thinks they ought to be able to, I'd have them filtering the goddamned newspaper.
I've been on LinkedIn since 2006. It's really gone downhill.
Networking is a fine thing to do and makes sense, at least given that HR departments don't actually do their job. Unfortunately, there is a large contingent of markety types who seem to think that networking and motivational crap can completely take the place of actually doing work. And they are dominating LinkedIn right now.
Now can we as a society please move on?
If, perchance, they actually listened to your argument, I'd say "yes, next let's move on to patenting business models" except I'd be more worried about some equally unlikely shit happening.
Like the Earth being swallowed by a black hole.
Obviously for the victim or his family it would be terrible, but once the scandal broke that the explosives had been planted on him by operatives there would no longer be any armed thugs in airports around the world, and we'd all be treated with a little more respect.
It wouldn't be worth one person's life.
Thanks for mentioning that; I absolutely didn't know about the editions feature.
It highlights, though, a big issue with Oracle: they have so many complicated features that their transactional model is incomprehensible. There's the standard commit, rollback and savepoints, then you have flashback, and you have the undo, and now you have editions.
(I probably have some details wrong, but in my defense I'm more of a software guy than a DBA, and I'm just not that interested in learning all things Oracle. Great system, I just wish it would get out of my way.)
From looking at the docs you linked to, I can see how it would be incredibly useful. Editions essentially allow the DBMS to allow multiple versions of the database. That's not what transactional DDL is though, and editions don't replace that functionality.
I don't think Oracle is going to offer that feature, incidentally, because very few of their customers actually want it. You only need transactional DDL is when you need to modify your schema dynamically. (And if you think you can _correctly_ modify a schema dynamically without it, you don't understand concurrency.) In a typical Oracle setup you're encoding business logic in the schema and you virtually never need or even want to do that. Your database not only represents but literally is a set of legal and financial obligations. You're just not going to want to create new rules on the fly or, worse, have those things disappear without a trace.
...especially if they don't want to be tech support for the rest of the friendship ;)
Which certainly won't last long with friendly advice like that!
Buddy, if someone's friendship is contingent on you providing professional services, that person is not really your friend.
I would have thought even after that, they'd still be curious as to how you put the dress on without it tearing...
Can you elaborate on the 'correct' with emphasis?
Google says that both postgresql and mysql get hits from 'incorrect results'. Are you stating that mysql's bugs have gone unfixed while postgre's have not? Or what?
For fairness, I'm going by MySQL version 5.5, the development version.
The default storage engine will quietly ignore foreign key constraints and transactions. source for default engine, claim that MySQL parses and ignores for non-InnoDB
There are multiple "SQL Modes" that can alter correctness, source, but by default the DBMS doesn't try to validate input. It's pretty confusing what mode does what, and I don't care enough to figure it out, but MySQL's approach has always been Do What I Think You Mean, and if they set the new version to be ANSI compliant by default it'd break all the existing sites built on it.
(I'm claiming this qualifies as "not being correct" by virtue of the Information Principle. Granted, SQL itself violates it in many ways, but MySQL proved that you can do worse than SQL.)
PostgreSQL has a far more correct transaction model. In some ways, they're actually better than Oracle. (In Oracle, a DDL statement will start a new transaction, whereas PostgreSQL wraps DDL into a transaction.) For starters, there aren't multiple "storage engines" per table with different transactional behaviors. source, sort of.
Also, PostgreSQL, to my knowledge, correctly validates input. It's kind of hard to cite a source for this since there's just no FAQ entry "Q. How do I configure PostgreSQL to silently corrupt my data? A. You can't." But by the same token, they don't have any long-standing terrible design decisions that they have to maintain compatibility with.
Sun bought MySQL so that Oracle can buy Sun and then the idea is to kill MySQL without running into any legal issues. If Oracle was to buy MySQL directly, then it is a no-no and it is highly the US government would let that happen.
Except for the small issue that MySQL is not a competitor to Oracle. PostgreSQL might be biting at their ankles. People who don't do this stuff for a living don't understand how important the M in DBMS is.
OurSQL sounds better :P
Not as good as YourMother.
CJ Date, who is almost as much of an old timer as Codd, notes that although he pronounces it as an acronym, sequel is also a common pronunciation.
source
Honestly, how is it acceptable for the police to lock someone in jail simply for refusing to obey a command?
It's less unacceptable than us, as voters, being disenfranchised because the laws our representatives wrote were ignored because the executive branch had no authority.
Yeah, FAT looked like a clever system when I was just learning and had never heard of a B+ tree.
From what I recall (FAT32 and exFAT both add structures and I'm only somewhat familiar with FAT32) FAT basically has a header (fixed at block 0, terrible for flash media) with a fixed list of root directory entries and the eponymous file allocation table. The FAT itself is just a list of every cluster in the media; each entry is either a link to the next block or an indicator if it's bad. Directories are allocated like files; they are a straight list of entries.
And that's *it*. Simplicity is fine, but, as common experience shows, it just isn't good enough.
Nobody outside of the USA refers to their mobile phone as a "cell". The most common usage in Europe...
So, "outside of the USA" == "Europe."
Let me guess, if a language is not English it must be Romance or Germanic?
FAT looks like someone's half-baked science project. FAT32 and exFAT (aka FAT64) just take the same mistakes and repeat them.
The fact that FAT32 is widely available is irrelevant; everyone will still have to install drivers.
So, yes, there's a demand for a simple (needing little CPU and RAM) filesystem. There's even an argument to be made that it should honor the same overall contracts that FAT does so that device manufacturers don't have to put lots of extra logic in. But it does *not* need to be the spawn of FAT.
Anyways I think age is mostly a state of mind.
No, youth is a state of mind; one of incomprehension and awkwardness alternating with overconfidence and self-righteousness.
Care to share your psychological theory about why people post hateful remarks on the Internet?
What kind of economics or math course teaches you to:
1. Read the fine print that says they won't ship your machine until the last payment.
2. Not divulge your SSN and mother's maiden name.
3. Check out the background of a retailer you're unfamiliar with.
Or anything else that might help people avoid this scam.
Don't get me wrong, math and economics are useful, but they don't teach you how to avoid cons.
Yeah, in European society, you've become so civilized and regulated that you're not really moral agents any more. How can a robot (the etymology is a treat) really be considered to commit a crime? It must simply be malfunctioning and be put in an attitude readjustment center.
Any kind of integrity constraints, even as simple as including enforcing types. You can kind of sort of do it with triggers but, like I said, you're reimplementing the DBMS. I speak from having _extensively_ implementing an EAV system and totally engineering myself into a corner with it.
The only thing you really gain is transactional support for creating / altering tables, but a good DBMS like PostgreSQL can do that anyway.
Those are phases of development, not types of projects. And nimbleness sucks when someone else has to figure out what you're doing, i.e. the maintenance phase.
Hey, good luck with it! I didn't have any PDFs up there, there are couple now. The section I'm working on is fairly basic mostly because a lot of people think they understand relational theory because they've used SQL DBMSs. Most of the actual language comes out in the next part.
However, the "rigid schema" claim bothers me. RDBMS can be built that have a very dynamic flavor to them. For example, treat each row as a map (associative array).
You described an entity attribute value model, which winds up reinventing half the DBMS, poorly. Don't worry, *everyone* does one once until they realize it's a bad idea.
Constraints, such as "required" or "number" can incrementally be added as the schema becomes solidified.
A "rigid" schema is preventing a ton of totally redundant code being written on the app side. All those constraints wind up in the schema because your UI designer doesn't want to consider that Mary might have 5 addresses or 6 mothers or work 7 jobs simultaneously. And your UI tester doesn't want to test an exploding combinatorial number of possibilities.
I'd like to see, however, a decent type system, proper logical / physical separation, etc.
Maybe also overhaul or enhance SQL. It's a bit long in the tooth.
I'm starting from scratch. (Currently I'm slowly retyping about 40 pages into Latex...)
That works, until the user is a bigger jerk than you are. I worked for a fairly senior enlisted man who was pretty bad about computer security. He related to me a story about how some system he needed to use generated a password for him, but it was totally random and he couldn't remember it.
There was no option, whatsoever, to generate any kind of "friendly" password or to make it memorable. So his solution was to call the help desk and to insist upon getting a password he could remember. The female tech started out, much as you suggest, by explaining that there was no way she would do that. He responded with 30-odd years of experience in yelling at people, which brought her to tears, and she wound up resetting the password until she got one he could remember.
The guy's pretty sharp about most things; he did a lot to straighten up record-keeping which definitely improved our operations, and probably did a lot to improve security overall. But he's that deadly combination of lousy at managing passwords and extremely effective at getting his way. So any plan that is "yell at people" has to account for the fact that the most critical individuals are liable to yell back.