Some posters here have very weird perspectives. Yes, if someone wants to extrapolate some straw man, based not on statements in the article or evidence from the real world, but built from whatever feels easy to criticize thoughtlessly, then sure, it is easy to knock that straw man down. Whatever.
For what it's worth, I liked The Stanley Parable and had a nice chat with the author of the game at PAX last year. Why would anyone assume that something like this is not the case?
You guys do know that the subjects of articles you read on the internet are other real people also on the internet, right? Why would a poster here assume that I am some kind of inert punching bag rather than, you know, someone who's been on HN for a couple of years and involved in discussions?
My reasoning for ranting was less directed at you and more at the idea that the article held up as you.
I never thought about it and hence never realised that my disagreement was misdirected. I regret not thinking before posting...
Duplicate values that should be unique is such a common problem if you don't use constraints.
This is a good example of why ACID and declarative constraints are a very good idea for data management.You can do a bad delete from query if you don't have the proper safeguards (though querying ability of SQL lets you more easily preview your changes), but the initial corruption of the data is an easily avoidable problem.
ACID isn't a banking issue, it's an issue in any database where data integrity is important. Having written administration software for life insurance companies, you can be sure that we designed our software to rely on ACID semantics.
Without transactions, correctly writing the software would have been far more difficult, especially in situations where you need to rollback a transaction that is partially completed because of system errors.
Even Google has admitted that they wish they had built transaction support into BigTable from the start. Instead each internal group tried to create their own hack.
Caring about branding things NoSQL isn't just not useful, it's harmful because it replaces really understanding things (like how a particular method works, and what it's good for) with a useless shorthand. Reminds me of a quote:
“You can know the name of a bird in all the languages of the world, but when you’re finished, you’ll know absolutely nothing whatever about the bird… So let’s look at the bird and see what it’s doing — that’s what counts. I learned very early the difference between knowing the name of something and knowing something.”
R. Feynman - "The pleasure of finding things out" 1981
I believe they are using SQL server, which keeps statistics on the most longest total runing, and longest per-run queries. It's a good idea to monitor this list and take a very close look at every execution plan that comes up. Many times you end up doing RID lookups due to non-clustered indexes that don't cover the requested data.
MSSQL is easier to optimize at last for me than say Sybase and Oracle, which I also supported.
People can bash MS as much as they want but their products are dirt simple to use and for the most part efficient. MSSQL comes with some query plan analysis so you can look at hit and miss ratios. From this info you can make some decisions as to add additional clustered or non-clustered indexes or use stored procedure which are saved (preprocessed) for faster execution. I forgot which of the several books I used to do this. But I was pleasantly surprised at the performance increase with my occasional tweaking.
Performance was not a priority for us that is why it was done occasionally. Not my call. My main job was make sure replications happened effectively, maintain good restores and security, and create stored procedures and triggers.
I hated the ORM in Rails. I do not want magic when I know how to do it more efficiently. For example there are certain times it is better to use DISTINCT versus GROUP BY for unique values.
I miss MSSQL. I use MySQL and it is ok but not like my sweetie and, thank you, not like the ugly gorilla Oracle.
The name relational model is quite unfortunate, as it leads to confusion about what the model is (not much to do with 'relationships').
The key concepts are using sets to store data (making you think about your data in a way where duplication of tuples and orderings don't mean anything), and always using values instead of pointers to store your data and references.
I think that these concepts are very useful when it comes to managing data, but they seem to get lost in the all the talk about "relationships" and "sql" and "structured tables".
One of the joys of working in F# is how the stronger type system combined with the type hover-overs allows for a sort of debugging-as-you-type that allows you to think with the help of the type system. It really helps unwind difficult problems and when there are errors you can easily see inline how to fix them. This is an impressive use of that facility, though it's even more useful when trying to solve a problem.
Inserting a default value is even worse than inserting NULL. Now you can't tell what data was wrongly inserted if you tried to clean up the mess later.
Correct, NULL is NULL, if the system is designed that it has to have a default value it should at least scream at you "I can't do NULL, you are going to get a 0 here". Or better yet just error at design time, not run time, and say sorry put a value here I don't do NULL. Run-time errors are the worst kind of errors and it is little unexpected behaviors like that, that can create huge problem in a run time environment.
Have you ever programmed SQL? Because what you wrote doesn't make sense.
No data is inserted wrongly - you are simply leaving out a field. There is no mess. Just an unused field.
Are you thinking it's like csv where if you leave out a column all the others are shifted? It's not like that.
The standard says if you leave out a column that does not have a default the SQL should return an error. Instead MySQL puts in a default (but only if you tell it too in the configuration). Putting a NULL in a non-NULL field would be much worse.
Oh I agree they are both very bad. Putting NULL in a non-NULL field is totally wrong.
However I really do think that inserting an unexpected default value is worse than inserting NULL into a NON-NULL field. The NULLs will cause problems, but they are problems you can see and resolve.
The default values are silent errors that will corrupt your data and be very difficult to recover from in the future. You can only guess which data was wrongly inserted.
I still don't see how it's possible to insert wrong data, or corrupt it??
There IS no data. How do you corrupt something that doesn't exist?
And NULL doesn't help either. NULL is valid data, NULL is not a replacement for programming errors (which is what this is).
This argument is pointless. People love to bash on MySQL, they look for the silliest things. The more popular something is the more people bash on it.
I understand that, but at least bash on real problems? Like the transaction DDL - that's a real problem. This? This is nonsense. (It's actually a very useful - and optional - feature BTW.)
NULL is not "default value" or "I don't care", NULL signifies "this might have a value, I just don't know what it is".
There is a very significant difference between a payroll record which states your pay is "0" vs. NULL. If the database is putting in default values, you have no way of knowing whether the employee really did have a salary, but it was incorrectly inserted as NULL, or whether the employee is unpaid.
I understand NULL very well, and that's not the only use for a NULL.
NULL also means "value does not exist", not just "value is unknown". For example if a student is not in a class, put NULL in the class id.
NULL is perfectly valid data, and is not a replacement for a programming bug.
And with mysql if your salary field is defined as accepting NULL then you will get a NULL in there.
And to use your example if the field accepts NULL, you would also have no way of knowing if the salary was not negotiated vs a programming bug.
If you want to argue the insert should fail, then fine, no problem. (And MySQL can do that.)
But arguing that putting in NULL is better (in a field that does not accept NULL), is simply wrong. I'll say it again: NULL is not a replacement for a programming bug - NULL is valid data, and should not be used to find programming errors.
> For example if a student is not in a class, put NULL in the class id.
I think you mean "don't insert a row in the student_class table, which is a many-to-many join between student and class".
As a general rule of thumb, if your data schema requires NULLs for things like that, then your schema is wrong, for most of the reasons that people are trying to point out. NULLs are the absence of data, and should really only be used for exceptional circumstances - hence the reason that silently inserting NULLs into NOT NULL fields is a Bad Thing(tm).
I find that F#'s (close to OCaml) type system helps me think through problems and lets me get correct programs faster, that somehow just seem to work correctly the first time.
Usually when writing a program in F# I usually write out the types of the functions I need first, before worrying about how the functions work. Because the type system is so descriptive I can validate that a plan to solve a problem is going to work before I start writing code.
Because the type system is powerful, when I need to make a change, it is simple to determine where my assumptions are broken and make the correct fixes.
> Usually when writing a program in F# I usually write out the types of the functions I need first, before worrying about how the functions work.
And that kind of things can give rise to such wonderful tools as hoogle (a type-based Haskell search engine, specify the type you need and it'll find the matching functions, whose types are often quite good insight as to their purpose)
http://indie-fund.com/about/