A comprehensive real estate database schema designed for property listing and management platforms. Includes property details with specifications, agent profiles, active listing management with pricing, customer inquiry tracking, and appointment scheduling for property viewings. Suitable for platforms like Zillow, Realtor.com, or custom real estate solutions.
A property and a listing are not the same thing, and separating them is the central decision here. properties holds what is physically true — the address, the bedrooms, the square footage, the year it was built. listings holds an attempt to sell or rent it: a price, an agent, a type and a window of time. The same house listed three times over ten years is one properties row and three listings.
Inquiries arrive against a listing, not against a property, because the question is always about this price with this agent. inquiries stores the sender's name, email and phone as plain columns rather than pointing at an account, since the people who ask about a house have usually never registered for anything.
Appointments carry both listing_id and inquiry_id, with the inquiry nullable. A viewing usually grows out of an inquiry and should stay attached to it, but a walk-in booked by phone has no inquiry behind it — and a schema that demanded one would force the agent to invent a fake message before booking.
Putting price on properties is the obvious shortcut and destroys history on the first price change. A property is listed, withdrawn, relisted at a different figure and perhaps rented rather than sold — each of those is a listings row with its own price, status and dates. The building's own attributes change rarely, so they stay where they cannot be overwritten by market activity.
Requiring registration before asking about a house is the fastest way to receive no inquiries. Holding name, email and phone on the row means the form works for anyone. What it gives up is identity: two messages from the same person are two unrelated rows, and deduplicating them is an application-level guess on email.
Sale and rental differ in what price means and little else at this level, so one listings table with listing_type covers both. The honest limit is that rentals eventually need a term, a deposit and a lease, none of which belong on a sale row — at that point the rental path earns its own table rather than more nullable columns here.
status says what the listing is now; expires_at says when it stops being that on its own. Storing the date means a stale listing can be filtered out by a query even if nobody remembered to close it, which matters because the thing people forget to update is exactly the listing that stopped selling.