In 10 years of fixing other people’s SQL databases, I’ve noticed that the less the original developer knew, the more complex the databases are … and the more complex the problems. Many of the issues which make developers hate SQL databases are caused by flawed initial designs.
As a developer, what you really need are some simple principles for how to think about designing your SQL databases so that they are simple, maintainable, expandable and easy to troubleshoot. I’ll introduce some easy basic rules hard-learned over 15 years of SQL database design and how to avoid some of the most common simple mistakes which take dozens of hours to fix in production.
Content will include:
Josh Berkus is primarily known as one of the Core Team of the world-spanning open source database project PostgreSQL. He has been involved with various open source projects since 1998, including SPI, OpenOffice.org, LedgerSMB, Bricolage and OpenBRR and is on the selection committee for OSCON. Currently, Josh consults on database performance and also makes pottery.
Comments on this page are now closed.
For information on exhibition and sponsorship opportunities at the conference, contact Sharon Cordesse at scordesse@oreilly.com
Download the OSCON Sponsor/Exhibitor Prospectus
Download the Media & Promotional Partner Brochure (PDF) for information on trade opportunities with O'Reilly conferences or contact mediapartners@ oreilly.com
For media-related inquiries, contact Maureen Jennings at maureen@oreilly.com
To stay abreast of conference news and to receive email notification when registration opens, please sign up for the OSCON newsletter (login required)
View a complete list of OSCON contacts
Comments
Is it possible to get the slides which were presented at this tutorial? Thanks.
What’s good: * this talk is good for novice DB designers/developers * good flow, but please add a slide at beginning to explain the set of high-level topics * good use of diagrams and examples * good use a slide animations, but make sure they work correctly * good “relation theory 101” but could use an example (rather than generic diagrams)
What’s not so good: * no need to “poo poo” other modeling techniques (ERD and UML) * your presentation (esp the beginning) seems to imply “big design up-front” (aka: Waterfall) which is not a recommended development practice; consider teaching (a) incremental development WITH (b) DB refactoring
Speaker: * comfortable and projects well * needs to remember to re-state the person’s question/comment for the audience
A/V * should have portable microphones * should have access to slides (esp in electronic for on; CD or thumbdrive or Web)