3 ms·

> Why? To allow others to impl the data store they want and to avoid having to write blog posts like these. It's not that much real work to quickly pull out a

> Why? To allow others to impl the data store they want and to avoid having to write blog posts like these. It's not that much real work to quickly pull out an iface on a stable system. Assuming it would be just mostly pass-through to your main impl anyways and this is a common approach in refactorization. You don't need some huge system, just drop it back a layer and abstract it. Often, what you end up learning about your system when you do this minimal work (again, nothing big) is that you screwed up and buried SQL and string concatenation and a bunch of other hard-to-review pieces all throughout your app because you keep a stranglehold on terms like YAGNI when separation of concerns has real value. Sometimes you also end up learning that your tests don't cover what you thought they did. Nobody wants bloat, but this adds very little and helps devs clamoring for alternative stores.

jimktrains2 9y ago
> To allow others to impl the data store they want and to avoid having to write blog posts like these. But why? For the longest time MySQL didn't support window function or CTEs. What do you do if you're using those? (I'm not sure of SQLite's window support, but I'm pretty sure it has CTEs.) If you're using postgres, should you not use pg_trgm (trigram indexer to use an index for regex searches on text), postgis (GIS tools), pg-routing (routing tools), ossp_uuid (uuid support), better types (boolean, range, inet, geometric, &c), or features such as RETURNING just because someone doesn't like my choice of database? No, I'm going to do what makes my life easier and my application faster and more featureful.
- kodablah 9y ago
  I think your talking about SQL abstraction and I'm talking about persistence abstraction. I would never consider sharing SQL across vendors.
  - jimktrains2 9y ago
    The way you persist has consequences to what types of features you'll build, and it'll end up being the least common denominator, not allowing you to use any advanced or efficient features of your store.
Analemma_ 9y ago
> To allow others to impl the data store they want and to avoid having to write blog posts like these. That's not a good enough reason. Those others need to first justify what the specific benefits of switching would be. I have a strong feeling that a lot of these people don't actually know why this change should be made beyond "I heard that SQLite 'isn't a real DB' but I don't know what that means". The customer is not always right; sometimes people making feature requests need to be told "No". > It's not that much real work to quickly pull out an iface on a stable system Maybe we've worked on different things, but this has not been my experience. IME, replacing a DBMS is agony, and adding an abstraction layer so you can use multiple DBMS's is agony exponentially magnified. Some of that is due to bad choices you made in the original design, but a lot of it is just because these systems will never behave identically, no matter what promises they make about SQL standards. Don't forget, also, that when you target multiple DBMS's, you're locking yourself into hitting the lowest common denominator of the intersection between their feature sets. You might end up making performance worse because you can no longer use DBMS-specific optimizations! But this is all immaterial: no matter how much or how little work it is, it's all unnecessary work. If there's no benefit to switching, why do any work at all, especially when it has all the downsides I mentioned above. > Often, what you end up learning about your system when you do this minimal work (again, nothing big) is that you screwed up and buried SQL and string concatenation and a bunch of other hard-to-review pieces.... I agree! So go through the app and fix those and then see if you still need to swap out the storage layer (which is actually what the author is recommending). Don't just do it because it's faddish before you've even established that it would actually add value.

jimktrains2 9y ago

> To allow others to impl the data store they want and to avoid having to write blog posts like these. But why? For the longest time MySQL didn't support window function or CTEs. What do you do if you're using those? (I'm not sure of SQLite's window support, but I'm pretty sure it has CTEs.) If you're using postgres, should you not use pg_trgm (trigram indexer to use an index for regex searches on text), postgis (GIS tools), pg-routing (routing tools), ossp_uuid (uuid support), better types (boolean, range, inet, geometric, &c), or features such as RETURNING just because someone doesn't like my choice of database? No, I'm going to do what makes my life easier and my application faster and more featureful.

kodablah 9y ago
I think your talking about SQL abstraction and I'm talking about persistence abstraction. I would never consider sharing SQL across vendors.
- jimktrains2 9y ago
  The way you persist has consequences to what types of features you'll build, and it'll end up being the least common denominator, not allowing you to use any advanced or efficient features of your store.

Analemma_ 9y ago

> To allow others to impl the data store they want and to avoid having to write blog posts like these. That's not a good enough reason. Those others need to first justify what the specific benefits of switching would be. I have a strong feeling that a lot of these people don't actually know why this change should be made beyond "I heard that SQLite 'isn't a real DB' but I don't know what that means". The customer is not always right; sometimes people making feature requests need to be told "No". > It's not that much real work to quickly pull out an iface on a stable system Maybe we've worked on different things, but this has not been my experience. IME, replacing a DBMS is agony, and adding an abstraction layer so you can use multiple DBMS's is agony exponentially magnified. Some of that is due to bad choices you made in the original design, but a lot of it is just because these systems will never behave identically, no matter what promises they make about SQL standards. Don't forget, also, that when you target multiple DBMS's, you're locking yourself into hitting the lowest common denominator of the intersection between their feature sets. You might end up making performance worse because you can no longer use DBMS-specific optimizations! But this is all immaterial: no matter how much or how little work it is, it's all unnecessary work. If there's no benefit to switching, why do any work at all, especially when it has all the downsides I mentioned above. > Often, what you end up learning about your system when you do this minimal work (again, nothing big) is that you screwed up and buried SQL and string concatenation and a bunch of other hard-to-review pieces.... I agree! So go through the app and fix those and then see if you still need to swap out the storage layer (which is actually what the author is recommending). Don't just do it because it's faddish before you've even established that it would actually add value.