RaPa Learning

The schema gives the organization of data. It says what the data means. In the previous example, the 'contact' column had the contact of a person and not an ID. That's what is given by a schema, in addition to the table-structure itself. Often, changes in schema require expensive migration - not only in the database, but also all applications that are using the database. As we saw in the previous example, we needed to change the country to an economic zone, but all zones were not ready to move at once. How can we reduce the burden of migration? Let's examine a few ways: Build some wrappers over the database. So when the structure of the database changes, we can still convert back to the old data. Retain the country and relate it to the region in a separate table: In this way, whoever needs the country can refer to that, and whoever needs the region will access it. This is a clever way that relies on modeling like the real world. Change the organization of the

Today's applications are powered by data, just like machines are powered by energy. In this series of blogs, we will look at how applications use data, how data is organized and what effect it has on the evolution of functionality. A professionally managed product will typically have this context: The product itself: X-ray equipment, Surgery devices, Ultrasound machines, toothbrushes and so on. A sales person would be in the process of getting a customer interested A customer would need consumables - like a new brush Many of these equipment produce images A customer would own one or more equipment A service engineer would service a set of equipment A product will have parts that are replaceable Spares would be stocked In today's world, each of these aspects are supported through applications. Application experience is enhanced with data. How do we store and correlate the data, so that it's usable? One way is to structure the data by modeling using Entit

A Relational Database models data in the form of tables and relation between tables. Consider the following application: When a customer asks a question about an equipment, we want to connect to an expert who can answer. For example, an expert on Ultrasound is different from an expert on X-ray; and there are different experts in different countries. One way to model this data is to make a table with the equipment identifier and the contact of the expert. As you can see, there's a lot of redundancy; the expert's contact is replicated in multiple rows. Not only is this inefficient in terms of storage, but also multiple updates need to be done when there's a new expert. How could we solve this? Any identification we repeat will have the same redundancy. The answer is to remove redundancy - normalize the data. The best normalizations are the ones that reflect the real world. In this case, the equipment and the region are linked to the contact. So one way to organize th

SQL is a language used to transact with a Relational Database. If you are unfamiliar with SQL, you can quickly get a flavor for it over here:  https://www.w3schools.com/sql/ SQL statements can be used to create, delete and update databases. The concept is based on the principle of transactions - till you commit a set of modifications, none of them are done. When you commit, all of them are done together. This way, 'integrity' of the data is guaranteed. However, strict schema management may have its downfalls... What if we need to add columns or the type of a column changes? What happens to applications that were written with old assumptions in mind? In the example we saw before, what if the schema changes? Let's say we discover that the economic zone is more important than the region. So we'd like to replace the region field. Economic zones have abbreviations like ASEAN, EMEA, etc. This change may be driven by considerations of cost: Costs are less when the pa