Remodeling Four Kitchens: A look inside our new brand
With the additions of Advomatic and Manatí, we’ve had an exciting few years at Four Kitchens. While we’ve remained fundamentally the same organization, we’ve also been evolving into something new. It’s time for our brand to catch up.Learn more
A more modern, sustainable approach to higher ed websites with YaleSites
A higher ed website is a product, not a project. Learn about Yale’s sustainable approach to digital development and how your team can do the same.Learn more
News and insights from the Web Chefs
Filter by topic
Filter by type
The CAP theorem is like physics to airplanes: Every database must design around it
Back in 2000, Eric Brewer introduced the CAP theorem, an explanation of inherent tradeoffs in distributed database design. In short: you can't have it all. (Okay, so there's some debate about that, but alternative theories generally introduce other caveats.)
Giving schema back its good name
For modern applications, the word "schema" has become synonymous with the tables, columns, constraints, indexes, and foreign keys in a relational database management system. A typical relational schema affects physical concerns (like record layout on disk) and logical concerns (like the cascading deletion of records in related tables).
Improvements to the Materialized View API
The Materialized View API (related posts) provides resources for pre-aggregation and indexing of data for use in complex queries. It does this by managing denormalized tables based on data living elsewhere in the database (and possibly elsewhere). As such, materialized views (MVs) must be populated and updated using large amounts of data. As users change data on the site, MVs must be intelligently updated to avoid complete (read: very slow) rebuilds. Part of performing these intelligent updates is calculating how user changes to data affect MVs in use. Until now, these updates had limitations in scalability and capability.
David’s epic presentation megapost
UPDATE 2009-06-08: You can download these slide decks (and more!) from our Presentations page. --The Web Chefs DrupalCamp Stockholm 2009 Is Drupal secure: the Drupal project's responses to the web's most common software vulnerabilities Scalable Drupal infrastructure: a guide to planning, deploying, and scaling big websites Drupalcon DC 2009 Building infrastructure you can scale, monitor, and maintain The next 10 Years: the future of application scalability and responsiveness
Schema changes should be lazy
We're in the middle of upgrading Drupal.org, and many of the longest-running upgrades involve schema changes. Unfortunately, MySQL with InnoDB has a very unfriendly method of doing schema changes: it rebuilds the table and blocks all writes until the new table is ready. A more sensible approach would be schema versioning that allows different parts of a table to have different schema versions. This would minimize blocking, allowing schema changes to happen without downtime.
Making the web a better place to teach, learn, and advocate starts here...
When you subscribe to our newsletter!