Thoughts on boss_db's active_record (not issue)

[liuzhen]

I have been working with boss_db for over a year, during which many frustrations and thoughts were developed:

1. Foreign Keys

Foreign keys combined with primary key (id) can be neat if we only use one database and will never vertically split into many. I got the lesson that I should make each table as independent as possible, which means no foreign keys at all, as we can manage table at will in case of splitting, data analysis, and so on.

1. Primary Keys

Always using id as primary key can simplify table logic. It does not hurt much until there is a third party responsible for the id (sequence, uuid) generating which is quite often in distributed db middleware or the like.

1. Counters

2.1 counters with primary key (id)

Primary keys (id) should never be involved into the biz logic (I am probably wrong), counters with primary keys makes it nearly unable to split db.

2.2 counters with non-structural 'name'

Tables keep change, counters change, too. But with non-structural counter name such as 'user-1029-counter-name', it becomes awful to manage. Wrapping my own counter logic so as to add more fields into the counter or even move counters logic to redis brings the control back.

my_counters table as: (user_id, service_id, other fields, counter_name, counter_value) would be much more clear and elastic.

2.3 counters mixing in all counters

all the counters are mixed into one counters table, which is cool but not quite maintainable. whenever part of the related logic is to be moved out, counters drags. Thus, make each counter table for each logic unless there is a reason not to.

[Gejove]

thx!a cult figure!

[liuzhen]

sorry to bother