network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 9 months |
| seen | Aug 14 '12 at 19:03 | |
| stats | profile views | 4 |
|
Aug 13 |
comment |
Designing an aggregation schema Also, I'm not sure I understand th Data Driven Joins description. Are you saying just store the "type" as a VARCHAR or similar, then have the application layer (business logic) handle the querying of the related data? If I want to ad a new type of data, then I'll need to add it only at the application level, along with the additional business logic for aggregating this data? |
|
Aug 13 |
comment |
Designing an aggregation schema For the Forest of Tables idea, what if you had a single activities table that relates an activityId to the users table's userId. Then you had other tables that relates other data to the activities table. This way you can use a JOIN instead of a UNION ALL. (I'm not sure if JOINs are faster) |
|
Aug 13 |
awarded | Student |
|
Aug 12 |
awarded | Editor |
|
Aug 12 |
revised |
Designing an aggregation schema added 567 characters in body |
|
Aug 12 |
asked | Designing an aggregation schema |
