Oddity Knowledge Base Collection guide

Building a Maintainable Database-Driven Website

5 min read Practical knowledge from OddityRead the article

A database-driven website stores structured information separately from the pages that present it. That can make a catalog, directory or resource library easier to maintain: one record can supply a detail page, a filtered list and a related-content section without somebody editing each appearance separately.

The benefit depends on the design of the whole system. A database does not automatically produce accurate content, a usable editor or a fast website. Those results require decisions about the information, the people maintaining it and the ways visitors need to use it.

Separate the information from its presentation

MDN's client-server overview explains how a dynamic website processes a request and returns a response. In a common arrangement, application code retrieves relevant records and uses a template to produce the page. The visitor receives the result, rather than direct control over the underlying database.

Consider a hypothetical training provider with a catalog of courses and scheduled sessions. A course description can appear on several pages, while each session has its own date and location. Keeping those facts structured allows a correction to the description to be reused consistently.

Choose the delivery approach according to the work. A small information site may be simpler to maintain with generated static pages, while a booking portal needs current application behavior. A database-backed publishing process can also generate static output. These approaches are options to combine, not stages every website must pass through.

Model the facts you need to maintain

For the training provider, a course and a scheduled session are different records. A course might describe the subject and prerequisites; a session supplies the date, venue and booking state. Copying the entire course description into every session would create more places for conflicting edits.

Frameworks provide tools for these relationships. For example, the Django 5.2 model documentation describes fields and relationships between models. The useful design question comes first, regardless of framework: which facts describe the same thing, and which facts need an independent identity?

Write down what a missing value means. An unknown session capacity should not silently become zero, and a course without a scheduled date should not be presented as cancelled. These distinctions affect the editor, public filters and any exported information.

Keep examples beside the rules

Try the model against a course offered at two venues, a postponed session and a retired course whose old link still receives visitors. These cases reveal more than a diagram containing only the easiest record. Decide how each should appear before filling the database with real content.

Give editors a clear publishing process

The editing screen should speak in the language of the work. For a session, show the course, date, venue and publication state together. Explain required fields where they are entered and make validation messages specific enough that an editor can correct the problem.

Separate saving from publishing when review is needed. A draft course description should be available to its reviewer without appearing in a public search result. Keep a revision history that shows what changed, who changed it and which version is public.

For the training provider, previewing a session should reveal the same date and venue that the public page will show. A preview built from a convenient demonstration record can hide a broken relationship. Include representative records in the review, especially ones with optional or unusual information.

Handle simultaneous edits deliberately

If two people open the same record, the second save should not silently erase the first person's work. Show when the record has changed and provide a way to review the conflict. This is a publishing requirement even when the database itself is operating normally.

Enforce access and safe data handling

Hiding an administration link is not access control. OWASP's authorization guidance recommends denying access by default and checking permissions on every request. Apply that check to the particular record and action, including previews, edits and exports.

For example, an instructor allowed to edit one course should not gain access to another simply by changing an identifier in a request. Public course descriptions and private participant records also need distinct access rules.

OWASP's SQL injection prevention guidance recommends parameterized queries to keep input values separate from SQL instructions. Filters and search terms need validation too. A convenient database library does not make unsafe custom queries harmless.

Rendering stored content raises a different issue. OWASP's cross-site scripting prevention guidance distinguishes context-appropriate output encoding from HTML sanitization. Plain text should remain text; intentionally supported rich HTML needs appropriate sanitization. Neither approach replaces authorization.

Plan for freshness, performance and recovery

Saving a record does not necessarily refresh every copy of a page immediately. MDN's HTTP caching guide explains how responses can be reused and distinguishes private from shared caches. Personalized responses require deliberate cache controls so another visitor does not receive private content.

For the training provider, test what happens when a session changes venue. Check the detail page, filtered listing and any cached view. Define how quickly that correction must become visible, then verify that the publishing process meets the requirement.

Use realistic catalog sizes when testing search and filtering. Return manageable result sets and measure slow requests before choosing an optimization. The first dozen demonstration records cannot establish how the site will behave after years of publishing.

Finally, practice restoring the database and the files the content depends on. A restored course record is incomplete if its required document has disappeared. Keep the recovery procedure connected to the actual website, and verify the recovered pages through the same public and editorial journeys people rely on every day.

Oddity Data Updates

Know when fresh data arrives.

Receive occasional notices about new and substantially updated database releases. No third-party mailing list.

Oddity Software

Details