Not long now until LinuxWorld Boston gets underway.

This year I've been conned into helping at the Apress booth on Thursday afernoon for a bit and will be meeting up with Jay and Jason for lunch. In the past I've gone over for one afternoon just to check out the exhibits. This year I'm also going to head over on Tuesday at 4 for the Golden Penguin Bowl, which should be fun:

Back by popular demand, it's the Golden Penguin Bowl. Expect an epic battle this year, as we bring you the riveting spectacle of Oracle nerds vs. MySQL geeks. Find answers to age-old questions like "What is your name?", "What is your favorite color?", and "What is the terminal velocity of an unladen swallow?" This …

Finally found time to fix Bug#16365, which is a request to add a limit for the total number of prepared statements in the server. It turns out to be a pretty useful feature, at least I was able to find 4 statement leaks in the test suite with it. The patch adds server variables to limit and monitor the count of prepared statements:

mysql> show variables like '%stmt%';
 ------------------------- ------- 
| Variable_name           | Value |
 ------------------------- ------- 
| max_prepared_stmt_count | 16382 |
| prepared_stmt_count     | 0     |
 ------------------------- ------- 
2 rows in set (0.00 sec)

Notice that this is slightly different from the status information, as in the status we account for all prepares and executes, including unsuccessful ones:

mysql> prepare stmt from "select 1"; prepare stmt1 from "select 2";
mysql> prepare stmt2 from "select …

A momentous occasion, Planet MySQL now has a total of 100 feeds! That's only 8 months after we introduced the new software and put some extra attention into it.

The 100th feed submission happened to come from Taneli Otala. Excellent! Meanwhile Brian has been nudging David to blog also....

Open Source gurus, I need your assistance.

Should I Open Source Adoppt or not?

Will it be a good idea to make the code available. Are there any ways I can continue paying my bills with OS?

Can OS be restricted to personal use only?

--Frank

Not very subtle title?

But look at databases, and applications using databases...
You've got your databases, tables and columns. Exciting? Or yawn...

Think of data, not by columns and type, but rather how it lives.

- Some data participates in "business logic" — what to show, how to show, related to other tables, etc.
- Some data changes often, some is literally static
- Some data needs to remain static, try Sarbanes-Oxley?, or J-SOX the Japanese counterpart
- Some data is small, but some is large (music, movies, pics)
- Some tables need to be transactional, some you couldn't care less

So, what — just cram it all in a database...?

Consider this — for each of the examples above, there is a penalty you pay, either in storage or performance for your choice.

What if you …

MySQL — or, as I was frequently instructed, you spell it My-Ess-Que-Ell?...

Something everybody learns when starting at MySQL — though few as forcefully as I learned, when staying my first few weeks with Monty.

Ok, so I'm no spring chick anymore... it took me two weeks to learn the mantra, and now I have been assimilated.
But, look at it from the lighter perspective — if that was the hardest part — then the rest is really easy.

If you can handle more Monty stories, check out the interview:
 http://dev.mysql.com/tech-resources/interviews/taneli-otala-mysql.html

But, what I really want to write about in this blog is about databases, or data management — future trends, how to make some entirely new and efficient applicatiions without changing too much. It's all about understanding the nature of data, not …

Not very subtle title?

But look at databases, and applications using databases...
You've got your databases, tables and columns. Exciting? Or yawn...

Think of data, not by columns and type, but rather how it lives.

- Some data participates in "business logic" — what to show, how to show, related to other tables, etc.
- Some data changes often, some is literally static
- Some data needs to remain static, try Sarbanes-Oxley?, or J-SOX the Japanese counterpart
- Some data is small, but some is large (music, movies, pics)
- Some tables need to be transactional, some you couldn't care less

So, what — just cram it all in a database...?

Consider this — for each of the examples above, there is a penalty you pay, either in storage or performance for your choice.

What if you …

Not very subtle title?

But look at databases, and applications using databases...
You've got your databases, tables and columns. Exciting? Or yawn...

Think of data, not by columns and type, but rather how it lives.

- Some data participates in "business logic" — what to show, how to show, related to other tables, etc.
- Some data changes often, some is literally static
- Some data needs to remain static, try Sarbanes-Oxley?, or J-SOX the Japanese counterpart
- Some data is small, but some is large (music, movies, pics)
- Some tables need to be transactional, some you couldn't care less

So, what — just cram it all in a database...?

Consider this — for each of the examples above, there is a penalty you pay, either in storage or performance for your choice.

What if you …

Not very subtle title?

But look at databases, and applications using databases...
You've got your databases, tables and columns. Exciting? Or yawn...

Think of data, not by columns and type, but rather how it lives.

- Some data participates in "business logic" — what to show, how to show, related to other tables, etc.
- Some data changes often, some is literally static
- Some data needs to remain static, try Sarbanes-Oxley?, or J-SOX the Japanese counterpart
- Some data is small, but some is large (music, movies, pics)
- Some tables need to be transactional, some you couldn't care less

So, what — just cram it all in a database...?

Consider this — for each of the examples above, there is a penalty you pay, either in storage or performance for your …

MySQL — or, as I was frequently instructed, you spell it My-Ess-Que-Ell?...

Something everybody learns when starting at MySQL — though few as forcefully as I learned, when staying my first few weeks with Monty.

Ok, so I'm no spring chick anymore... it took me two weeks to learn the mantra, and now I have been assimilated.
But, look at it from the lighter perspective — if that was the hardest part — then the rest is really easy.

If you can handle more Monty stories, check out the interview:
http://dev.mysql.com/tech-resources/interviews/taneli-otala-mysql.html

But, what I really want to write about in this blog is about databases, or data management — future trends, how to make some entirely new and efficient applicatiions …