28. SELECT
Program,
Month,
ThisYearTotalRevenue,
PriorYearTotalRevenue
FROM (
SELECT
ISNULL(ThisYear.Program, PriorYear.Program) as Program,
ISNULL(ThisYear.Month, PriorYear.Month),
ISNULL(ThisYear.TotalRevenue, 0) as ThisYearTotalRevenue,
ISNULL(PriorYear.TotalRevenue, 0) as PriorYearTotalRevenue
FROM (
SELECT Program, Month, SUM(TotalRevenue) as TotalRevenue
FROM PVMonthlyStatusReport
WHERE Year = @FinancialYear
GROUP BY Program, Month
) as ThisYear
FULL OUTER JOIN (
SELECT Program, Month, SUM(TotalRevenue) as TotalRevenue
FROM PVMonthlyStatusReport
WHERE Year = (@FinancialYear - 1)
GROUP BY Program, Month
) as PriorYear ON
ThisYear.Program = PriorYear.Program
AND ThisYear.Month = PriorYear.Month
) as Revenue
WHERE
Program = 'Bikes'
ORDER BY
Month
29. SELECT
Program,
Month,
ThisYearTotalRevenue,
PriorYearTotalRevenue
FROM (
SELECT
ISNULL(ThisYear.Program, PriorYear.Program) as Program,
ISNULL(ThisYear.Month, PriorYear.Month),
ISNULL(ThisYear.TotalRevenue, 0) as ThisYearTotalRevenue,
ISNULL(PriorYear.TotalRevenue, 0) as PriorYearTotalRevenue
FROM (
SELECT Program, Month, SUM(TotalRevenue) as TotalRevenue
FROM PVMonthlyStatusReport
WHERE Year = @FinancialYear
GROUP BY Program, Month
) as ThisYear
FULL OUTER JOIN (
SELECT Program, Month, SUM(TotalRevenue) as TotalRevenue
FROM PVMonthlyStatusReport
WHERE Year = (@FinancialYear - 1)
GROUP BY Program, Month
) as PriorYear ON
ThisYear.Program = PriorYear.Program
AND ThisYear.Month = PriorYear.Month
) as Revenue
WHERE
Program = 'Bikes'
ORDER BY
Month
Be clear, scaling is about getting bigger, not getting faster.
The web is high read, low write. High volume.
Shoehorning objects into relational models. Serves us well, but options exist.
Couch pros: good at being disconnected for long time, good replication. Cons: REST only, replication as scaling
Tokyo Cabinet: great replacement for BDB
replica pairs and master-slave configurations.
MVCC (Multiversion concurrency control) of couch vs update in place of mongo.
MVCC very good at master-master, often offline, problems requiring versioning.
Update in place offers killer write speeds and updates.
Mongo replication really geared toward failover and updates.
SQL plans usually go into production untested since they can change with new data. That can mean production down. Statistical query optimizers change when the table statistics change. That means UNPREDICTABLITY.
Wicked plans. Mongo runs multiple plans and learns from them. First one to the finish wins.
Latency is bad. CouchDB is cool and all, REST and HTTP is awesome. But the point of using nosql is usually speed. Why give that up for something as simple as connections?
Canonical example: Website Analytics.
LRU’ed out
caching
logfiles
history/activity/streams
Modifier Operations
Update if Current
Nice mapping to dynamically typed languages.
Makes migrations and updates to the database smooth. (Think mysql locking tables to add column).
If code isn’t solid, you can get into trouble.
Preserves datatypes unlike straight JSON.
Binary data like videos, images can be stored directly in BSON, unlike as attachments in CouchDB.
Still have to deal with form strings in many cases.
