@lucas1 said in Is ruby dying?:
@Groaner most SQL databases offer a Json type now as well. But I have no idea why you would want to use it.
Persistent events. There's often a lot of variation between events, and not much you really care about querying.
Choices are basically: a table per event type, a big events table with a TYPE column with many nullable columns, or a big events table with a TYPE column and a serialized blob of all the event-specific fields.
For example, lets say I had a CLIENT table, and wanted to store all events which cause a change in a CLIENT_EVENT table.
Using a JSON column, it could look something like:
Event ID | Timestamp | Client ID | Type | Event Data |
5 | 2016-11-02 09:24 | 4 | Created | { firstName: "William", lastName: "Doyle", birthDate: "1970-03-05", emailAddress: "william@example.com" } |
21 | 2016-11-03 14:32 | 4 | BirthdateAmended | { birthDate: "1970-05-03", reason: "Was written in month/day/year format instead of day/month/year" } |
37 | 2016-11-04 12:44 | 4 | NameChanged | { firstName: "Bill", lastName: "Doyle" } |
429 | 2016-12-04 13:21 | 4 | Deleted | { reason: "Bludgeoned to death with an avocado :(" } |
I could have these as separate tables for each type, but I don't really see a benefit to it and the effort to maintain them would grow larger as more event types get added. Similarly, I could have a single CLIENT_EVENT table with many columns, but it wouldn't really be clear which columns are used in which event types.