Timeline for Designing pricing table (RDBMS agnostic)
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 4, 2021 at 10:47 | comment | added | Tulains Córdova |
@aderchox Agreed price is a price agreed upon with a client that may differ from the official price, you may use price instead. Regarding your second question, you make a query joining PRICE_HISTORY with PRODUCT thru PRICE table. This is a conceptual diagram, PKs are omitted but infered. This query would link every row in PRICE_HISTORY with their product: select h.price, h.date_changed, r.name as product_name from price p join price_history h on (p.price_id = h.price_id) join product r on (p.product_id = r.product_id)
|
|
| May 2, 2021 at 22:37 | comment | added | aderchox | Can you please make it clearer what the "agreed_price" is? Also how does price_history know about which product each of its records are? | |
| Nov 6, 2017 at 15:16 | comment | added | Walfrat | Also if we consider a table big enough, separating history data from active ones is a must. | |
| Aug 8, 2017 at 16:44 | comment | added | Tulains Córdova | @JamesAnderson A dummy date is a date nontheless whereas a non-existant datum is a null datum and should be left null. That's what NULL is made for. | |
| Aug 8, 2017 at 4:33 | comment | added | James Anderson | Dummy date is actually better than null as a " < End_Date" will always evaluate false requiring the clumsy "( ? < End_Date or End_date is Null )" | |
| Jul 12, 2016 at 20:04 | history | edited | Tulains Córdova | CC BY-SA 3.0 |
added 84 characters in body
|
| Jul 12, 2016 at 19:49 | history | answered | Tulains Córdova | CC BY-SA 3.0 |