In Pakistan, gold and silver are not abstractions, they are weddings, savings, and Eid gifts, and everyone checks the rate. The rate people actually use is quoted per tola in the Sarafa markets, and finding today’s number online means wading through cluttered pages. I decided to build a clean, live gold and silver rate site for Pakistani cities, silverrates.today, and this post is the foundation, including the unit maths and the schema everything else stands on.
First, the domain knowledge that shaped the code. The tola is the unit that matters, and it equals exactly 11.664 grams, a conversion constant the whole plugin leans on:
function srt_tola_to_gram($per_tola) { return $per_tola / 11.664; }
function srt_tola_to_10gram($per_tola) { return ($per_tola / 11.664) * 10; }
Rates get quoted per tola, per gram, and per ten grams depending on the audience, so storing one canonical unit, per tola, and converting on display keeps the data honest and the maths in exactly one place. Gold adds purity, 24K, 22K, 21K, 18K each have their own price, most jewellery is 22K while savers buy 24K, so a gold rate is really four numbers. The rates table reflects all of it:
// wp_srt_rates: one row per city per capture
// city | gold_24k | gold_22k | gold_21k | gold_18k | silver | recorded_at
function srt_get_latest_rate($city = 'Pakistan') {
global $wpdb;
return $wpdb->get_row($wpdb->prepare(
'SELECT * FROM ' . $wpdb->prefix . 'srt_rates
WHERE city = %s ORDER BY recorded_at DESC LIMIT 1',
$city
));
}
Two decisions hiding in that schema repaid themselves for months. Rates are appended, never overwritten, every capture is a new row with recorded_at, which means history exists for free, the price trend graphs later in this series are just queries over this table. And city is a column from day one, because rates genuinely differ slightly between cities through local demand and dealer premiums, and the plugin ships a helper, srt_default_cities, returning the fifteen cities the site covers, Lahore, Karachi, Islamabad, Multan, and the rest. One table, honest units, history by design, and a city dimension, everything the next eleven posts build on lives in those choices.
A few things people ask me about this
Why store per tola instead of per gram? Because the market quotes per tola, so per tola is the observed fact. Grams are derived, and deriving on display through one conversion function means no stored number is ever a calculation that could drift.
Why keep old rates instead of updating one row per city? Appending preserves history, which powers trends, comparisons, and honesty about when a number was captured. Overwriting saves trivial space and destroys all of that.
Next
One table of rates had to become dozens of pages, tables, graphs, and calculators. The engine that did it, city-aware shortcodes, is the next post.