Showing entries 11 to 14
« 10 Newer Entries
Displaying posts with tag: engineering (reset)
MySQL reengineering project

Here's another chapter of the MySQL evolution saga.

We know that MySQL today, although hugely popular and effective, has many shortcomings. A Refactoring effort has been announced, after a few months of internal discussions.

The effort is open to external contributions. There is a mailing list for discussing the "what" and the "how" of the new path.

The goals of the project are basically

  • Modularity. Make it easier to add new features without breaking existing ones.
  • Pluggability. Make it easier for third parties to add functionality.
[Read more]
MySQL reengineering project

Here's another chapter of the MySQL evolution saga.

We know that MySQL today, although hugely popular and effective, has many shortcomings. A Refactoring effort has been announced, after a few months of internal discussions.

The effort is open to external contributions. There is a mailing list for discussing the "what" and the "how" of the new path.

The goals of the project are basically

  • Modularity. Make it easier to add new features without breaking existing ones.
  • Pluggability. Make it easier for third parties to add functionality.
[Read more]
MySQL reengineering project

Here's another chapter of the MySQL evolution saga.

We know that MySQL today, although hugely popular and effective, has many shortcomings. A Refactoring effort has been announced, after a few months of internal discussions.

The effort is open to external contributions. There is a mailing list for discussing the "what" and the "how" of the new path.

The goals of the project are basically

  • Modularity. Make it easier to add new features without breaking existing ones.
  • Pluggability. Make it easier for third parties to add functionality.
[Read more]
The principle of cautious design

Whenever we are faced with a choice between two designs, and the first design is upward compatible with the second (i.e. the first design is more restrictive, and implementing design two would not affect functionality provided by design one), and the full impliciations of the second design are not yet known, the first design choice is recommended.
Formulated by C.J. Date in "Relational Database: Writings 1989-1991"

Showing entries 11 to 14
« 10 Newer Entries