I believe all they were trying to do was to keep the whole data thing as simple as possible, while sacrificing no detail. They couldn't afford to waste time on avoidable steps to achieve any given end. Somehow, people figured out that all the numbers everybody needs in human life can be handled with the ten digits. Pioneers in physics make new math, with new symbols, in case we ever venture to the edge of multiverse where we would need it. For simplicity, let's assume none of that matters for our immediate needs. Ten digits. A decimal marker. Commas for style. All numbers work perfectly with this simple system. The Roman system was not like that. That is why it died. In 1967, two guys at IBM published a paper about the math of data (it might have been two papers). Their names were Chris Date and Ed Codd. Their model for data covers what data is. It's called the relational data model. SQL speaks relational. They invented SQL as language to express the math they devised. It has only a few words, like there are only a few digits. Here are the words that define data. These are the forms data takes in their system: Field/Column Row (of fields) Table (of rows) Database (of tables) Server (of databases) How can all data fit into that? Answer: How many columns can you put in a table? All kinds of functionality is avialable through the sql language for manipulating those things listed above. Enter normal humans, who do not think in rows of fields. They are more creative. No data they create can not fit perfectly, with no loss of meaning or detail, into fields in rows in tables. Either they cooperate with the machines we have built for 40 years to operate with increasing efficiency and flexibility on those items, or they insist upon Roman numerals. Subfields can be reached by string functions that can parse fields into sub fields. So, your program can say Select name, Or select (substring data, (function to say where to start), function to say how many characters), as name this can get complicated. Avoid subfields. You will have them, they are inevitable, but avoiding them will produce more of the system you want in a given amount of time, Ted Codd, Chris Date
Holly's system relies on subfields. Subcodes are mashed together into one field called "product code." Examples: 01-CHARACTERCL-SP-9_95 DISC25-01-CHARACTERCL-SP-9_95 How To Revise Your Novel 01-HTYRN-SP-277 01-HTYRN-5-SUB-57 DISC20-01-HTYRN-SP-221-60 DISC20-01-HTYRN-SUB-5-45-60 01-HTRYN-SP-377 01-HTRYN-5-SUB-77 DISC10-01-HTRYN-SP-339-30 DISC10-01-HTRYN-5-SUB-69-30 DISC20-01-HTRYN-SP-301-60 DISC20-01-HTRYN-5-SUB-61.60 DISC15-01-HTRYN-SP-320-45 DISC15-01-HTRYN-5-SUB-65-45 01-HTTS-CANARY-SP-347 01-HTTS-CANARY-7-SUB-50 01-HTTS-2016-SP-497 01-HTTS-2016-7-SUB-77 01-HTTS-2016-SP-BC-397 01-HTTS-2016-7-SUB-BC-62 HTTS-CANARY DISC30-01-HTTS-BIGLAUNCH-SP-347 DISC30-01-HTTS-BIGLAUNCH-7-SUB-50 00-FLASHFICTION-SP-0_00 01-PLOTCL-SP-9_95 01-LANGUAGECL-SP-9_95 DISC25-01-PLOTCL-SP-9_95 DISC25-01-LANGUAGECL-SP-9_95 01-HOWTOMOTIVATEYOURSELF-SP-77 DISC30-01-HOWTOMOTIVATEYOURSELF-SP-53_90 This is the data we have that separates the subfields into fields of their own: Code: SELECT distinct prod_code as product_code FROM `product_codes` pc inner join product_master pm on pm.skey=pc.prod_skey where pm.skey IN(9,10,11,1,19,2,3) and dryrun=0 ORDER BY rank, pc.`skey` ASC Code: SELECT prod_code as product_code, product_name, payments, price , pm.skey as prod_skey, pc.skey FROM `product_codes` pc inner join product_master pm on pm.skey=pc.prod_skey where pm.skey IN(9,10,11,1,19,2,3) and dryrun=0 ORDER BY rank, pc.`skey` ASC
