4 ms·
Well, thanks for the response, despite the downvote. That said, it may seem like a 'bad' idea, as I understand the pitfalls in managing a consistent data schem
by bmelton 16y ago
Well, thanks for the response, despite the downvote. That said, it may seem like a 'bad' idea, as I understand the pitfalls in managing a consistent data schema across n databases, but it also seems like a much more performant idea than building a customer table and having to do an extra join on every read query for every ticket for every logged in user.
- deleted 16y ago[deleted]
- danieldon 16y agoI didn't downvote you, bmelton. it also seems like a much more performant idea Why is performance important to you? Presumably to make it cheaper to run, in which case I suggest you weigh the costs of coding and maintaining multiple dbs against the cost of that extra join. Note that the multiple db approach is already costing you since you are still trying to get it to work while you could already gave the single db approach in place relatively painlessly.