SQL triggers is something that everybody heard a lot about. Before start we need to talk about benefits and burdens.
###+
It’s very very fast. If you are using any kind of adapter you pay for all this wrappers and connectors. If it’s trigger – all operations are very cheap because they are provided by PostgtreSQL.
It works like a magick. There is no code on your repository, there is no any callbacks on your models and so on.
###-
It works like a magick. You can’t easy determine all operations. All this \df+ stuff and so on.
It’s hard to change. Really if you want change trigger you need to drop it and hang it again. With full trigger code. You can use hair_trigger to simplify it but anyway.
It increases requirements to your developers. Really, thay should now SQL. In perfect world your team is awesome. But it’s business.
It will cause some problems in cause if you are using STI because you can’t define model by it’s tablename.
It can cause problems on backups restoring. On restoring large tables somebody can use --disable-triggers to speed up process and it’s not that you are expecting.
If you are still want it let’s continue. You have MobilePhone, Laptop and Ad. Ad contains info about Product (in this case MobilePhone or Laptop). You want to provide some kind of faceted search for your products. We will use extension pg_trgm for searching products with name similar to provided by user.