Howfuckedismydatabase
howfuckedismydatabase.com
howfuckedismydatabase.com
Bob: So, how do I query the database?
Ed: It's not a database. It's a key-value store!
Bob: Ok, it's not a database. How do I query it?
Ed: You write a distributed map reduce function in Erlang!
Bob: Did you just tell me to go fuck myself?
Ed: I believe I did, Bob.
Warning: oci_connect(): ORA-$$$$: Insert coin to continue
At my last job we used Postgres on a Windows server. Whoever initially set up the database pretty much stuck to the defaults.
Whenever we would read/write text to the db in code we were using functions that basically returned raw data. All of our text was encoding using UTF-8.
When using the Windows Postgres Admin tool to run a query that returned text, you'd occasionally see some weird characters (café), sometimes you wouldn't (café). Sometimes the query would fail due to invalid characters.
When I looked into it I quickly realized what was wrong - on Windows Postgres defaults to Win1252 encoding (which is a form of extended ascii). Normally when you are writing text to the database Postgres will convert the encoding but since we were writing raw bytes we skipped this part.
Win1252 contains some undisplayable characters which occasionally show up in a multi-byte UTF-8 character, explaining the failed queries. However it didn't explain why sometimes we got café and sometimes we got café.
It turned out that there were some scripts/apps that were reading file names on Windows and inserting them into the database without converting it to UTF-8. Windows uses UTF-16, although somewhere this was auto-magically being converted to Win1252.
This meant that our Win1252 encoded database contained both Win1252 text and UTF-8 text. I ended up doing a text dump of the database and writing a Perl script that would run through it all byte-by-byte and convert all characters above ascii 127 that were not part of valid UTF-8 sequences into UTF-8. This was then used to create a new database correctly encoded as UTF-8. It actually worked (although there were a few snags - we were getting some data from this service that would randomly include the sub character (ctrl-z) occasionally which would cause cat/split to stop running).
(The Oracle < $1m answer is a RIOT.)
“After reviewing your site, I'm so glad we are sticking with emailed Excel spreadsheets for our mission critical database requirements.”
And:
“Databases? Fuck that. I use Excel's pivot tables.”
I recently realized that with programming languages, it's similar, but not quite the same. Runs fast, has libraries, isn't totally frikkin braindead: pick one, if you're lucky.
Just now I realized that much the same applies to databases.
In IT services (or web design, or whatever, really), my first exposure to it was "Good, Fast, Cheap; Pick any two."
Fast, Quiet, Cheap
Either it is: intentional -> High five for charity. an accident -> He really missed out on the $2-$6 CPC of the glorious database keywords... especially without having a button to go back. This page has what, 144 pts? That usually rounds off to 10000+ page views from my perspective. 1429 tweets, so maybe toss in an extra 7000 or so. That's at least $51~ he could have raked in based on 17k views times $3 avg a mille. :(
If anything, I wish it was more complex though.
Microsoft JET Database Engine error '80004005' Table 'tblTable' is exclusively locked by user 'Admin' on machine 'MyMachine'.
Ahhh there it is..
Warning: sqlite_open(): file is encrypted or is not a database in /var/www/database/sqlite/common.php on line 10
// Quick hack, will fix properly soon!
It was dated sometime in the 80's.
Really.
Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL: database "postgreserrors" does not exist in /var/www/database/postgres/common.php on line 10Re OP: Ah, the joys of being a Sybase user, nobody even makes fun of us.