DB
A simple database
The simplest database in the world consists of:
- an insertion method (
db_set)db_set 123456 '{"name":"London","attractions":["Big Ben","London Eye"]}'
- a retrieval method (
db_get)db_get 42
- a text file, as a log (meaning append-only) of key-value pairs
The write speed of this database is very fast because data is simply appended, but the read speed is very slow, at 0(n)
If we wanted to speed this up, we could use an index
many databases internally use a log, which is an append-only data file.
Foward and Backward Compatability Requirements of Databases
in an environment where the application is changing, it is likely that some processes accessing the database will be running newer code and some will be running older code—for example because a new version is cur‐ rently being deployed in a rolling upgrade, so some instances have been updated while others haven’t yet.
- This means that a value in the database may be written by a newer version of the code, and subsequently read by an older version of the code that is still running. Thus, forward compatibility is also often required for databases.
The living nature of a database
When you are designing a database with relations, you have to consider that the database is a living object. At any moment in time, you have definitions and purposes of each specific model. However, as the needs of the database change and grow with your business, you need to be flexible to change the definition of models that no longer makes sense, given that business logic
- For instance, we previously had the concept of a payment profile in the database, which was basically a credit card. Therefore, you might find a payment profile as "a way to pay". However, within corporations have coupons into the payment system, it became apparent that a coupon was really not to do similar from a credit card in the way that it would function. Therefore, it made sense to change the way that we thought of a payment profile. Incorporating coupons into this model meant reconsidering the name. Instead of payment profile, they would be called payment methods. Now the definition became something more like "some type of exchange good that you can pay with to receive a good in return". By allowing this definition to change, we were able to leverage existing functionality to incorporate new and unexpected designs into the database model.
Access Pattern
Database should be designed around the way that you plan to access and use the data
Analogy: Lego
Imagine having a big box of lego with 1000s of pieces mixed altogether. This would naturally be difficult to go through and pull out the pieces we need. Now, consider how we are using the lego. Maybe we are following the schematic of building a car, or maybe we are building something a little more ad hoc. In the first case, the color and shape of the piece matters, but maybe in the second case we only care about the shape. In the first case, we might benefit from first separating the pieces into separate piles based on their color. In the second case, maybe it makes more sense to separate the pieces into piles based upon their shape.
This analogy helps us think about the importance of the data access pattern. Whether we are building from a schematic or in an ad hoc way, our priorities change and we think differently about how we want to organize the lego pieces so that we can find them easier.
Children