Re: Thoughts on "Love Your Database"

Yeah but your already paying for a developer ...

On Wed, May 4, 2016 at 2:36 PM, Szymon Lipiński <mabewlun(at)gmail(dot)com> wrote:

>
>
> On 4 May 2016 at 20:20, Will McCormick <wmccormick(at)gmail(dot)com> wrote:
>
>> I 100% agree with you. It's always been a problem but it is up to us to
>> take ownership and provide value. Some would be surprising shocked how
>> simple it is to manage the Data access layer once the framework is in place
>> regardless of what it is written in. For the same reasons you wouldn't
>> typically have Application Developers configuring your production disks for
>> high performance... why would you ever have them access the database
>> inefficiently? There is an assumption designers are good at SQL or at least
>> know it ... I challenge you to flip that around and learn the Data Access
>> Layer. Companies do not knowingly spend money on hardware to have it
>> consumed by inefficient data access? No executive signs up to increase the
>> TCO and reduce profit margins when they could be making more money? But
>> this is far to often the case and the root cause is they did not have the
>> right tool (pun not intended) for the job.
>>
>> On Wed, May 4, 2016 at 1:33 PM, Szymon Lipiński <mabewlun(at)gmail(dot)com>
>> wrote:
>>
>>>
>>>
>>> On 4 May 2016 at 19:09, Will McCormick <wmccormick(at)gmail(dot)com> wrote:
>>>
>>>> I agree that it's not like turning on the light switch. And I'm not
>>>> implying there isn't a logic layer between the database and the
>>>> application. Based off my past experiences I would likely not put business
>>>> logic in the database unless it was a critical for performance. This does
>>>> not make it portable and does the performance of my product require it? It
>>>> really comes down to the application there is not one big paint brush. We
>>>> have all be around and get this. I would not likely design a solution that
>>>> had the database and the application layers both containing the business
>>>> logic. I have seen this and the unexpected behavior as assumptions are made
>>>> on both ends of that spectrum. I like to keep it simple where I can. This
>>>> all being said I think database minded folks should own DAO's. I think if
>>>> your a database guy and you don't own the DAO's you are missing an
>>>> opportunity to really make a difference and get more aligned with your
>>>> development staff. Doesn't matter what code base DAO's are in it's a
>>>> repetitive pattern that any database person can pick up.
>>>>
>>>> On Wed, May 4, 2016 at 12:29 PM, Szymon Lipiński <mabewlun(at)gmail(dot)com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 4 May 2016 at 18:14, Will McCormick <wmccormick(at)gmail(dot)com> wrote:
>>>>>
>>>>>> I agree it's typically political but so are most things business.
>>>>>> Examples: Companies buy other companies - You are using a competitors data
>>>>>> store and want to replace it. Company needs to compete with competitors
>>>>>> and wants to reduce cost ... these are not technical requirements and it's
>>>>>> certainly not vapor ideology. I have only worked for startups and have seen
>>>>>> this happen at every company i have worked for, yes it is political but yes
>>>>>> it happens. Smaller companies are more susceptible to it.
>>>>>>
>>>>>> The reality is somewhere in the middle as it often is. My point is
>>>>>> you don't have to replace a million lines of code if you plan upfront. If
>>>>>> you don't .. you do.
>>>>>>
>>>>>>
>>>>>> On Wed, May 4, 2016 at 11:29 AM, Uwe Schroeder <uwe(at)oss4u(dot)com> wrote:
>>>>>>
>>>>>>> On Wed, May 04, 2016 11:05:25 AM Will McCormick wrote:
>>>>>>>
>>>>>>> A reason to consider may be portability. What happens if I want to
>>>>>>> let my customer chose their data store or I just don't want to put all my
>>>>>>> eggs in one basket.Technically there are truths but you cannot ignore the
>>>>>>> business side either. If a we can exceed our performance requirements and
>>>>>>> keep things generic/portable this is the best of both worlds.I think this
>>>>>>> is the main reason people separate the business logic from the database.
>>>>>>> How many of you have ported databases between platforms? Or had multiple
>>>>>>> types of data stores in the same company?
>>>>>>>
>>>>>>> I have been waiting for the portability argument for the last 20+
>>>>>>> posts :-) Everyone who did any type of consulting/working in this
>>>>>>> field knows that latest the second argument from management is
>>>>>>> “portability”. I have yet to see anyone who really needed to move to a
>>>>>>> different database. If they did it usually is a political issue and not a
>>>>>>> technical one (uhh, we hired this new operations manager and MS SQL is so
>>>>>>> much better than postgresql …) Unless you develop a generic software to be
>>>>>>> sold to many clients, the choice of data storage is rarely a real concern
>>>>>>> unless someone who feels the urge to be important starts throwing words he
>>>>>>> read in a magazine at management. None of my clients ever questioned the
>>>>>>> database. They either had one which they wanted to use (i.e. they had a big
>>>>>>> iron IBM with DB2 on it plus a DBA who knew what he was doing) or they
>>>>>>> didn't care as long as it worked as expected and came with a maintenance
>>>>>>> contract of sorts.
>>>>>>>
>>>>>>> If you're developing a web application, the least concern is
>>>>>>> portability (you're not going to replace the million lines of PHP either).
>>>>>>> The biggest concern should lie with data integrity and API's that protect
>>>>>>> your data and business logic so you can hire that cheap app development
>>>>>>> company from overseas your boss recommended (based on a spam email) without
>>>>>>> running the risk of compromising everything.
>>>>>>>
>>>>>>> Uwe
>>>>>>>
>>>>>>
>>>>>>
>>>>> I'm not sure that when a company buys another company they can just
>>>>> migrate the other database without any logic layer. The data is usually
>>>>> useless without the business layer which tells how to merge all the parts
>>>>> together to have a simple answer to a question like "do we have this in
>>>>> stock". And for such a migration that's not too important if we have the
>>>>> logic in database, or in some other layer. Of course it is always simpler
>>>>> to migrate a database treated like a CSV file, where all the logic
>>>>> (including constraints) is in an external application. But do we really
>>>>> want that?
>>>>>
>>>>> On the other hand, when I was trying to store all my logic in a
>>>>> database, there was just one thing that made me hate it. Testing. Testing
>>>>> the procedures inside the database was not easy, not funny, and too much
>>>>> time consuming.
>>>>>
>>>>> --
>>>>> regards Szymon Lipiński
>>>>>
>>>>
>>>>
>>> I also wouldn't keep the logic in a database. And the DAO layer is the
>>> best solution I know. The biggest problem I experienced was that there was
>>> no DBA in a team, management didn't see any problem with that, and the DAO
>>> layer was managed by random programmers who didn't want to learn databases.
>>> The results were mainly two: slow development (due to too many bugs), and
>>> slow application (due to bad queries).
>>>
>>> It seems like there is no problem with storing logic anywhere, the
>>> problem is with having someone who knows how to write it.
>>>
>>>
>>> --
>>> regards Szymon Lipiński
>>>
>>
>>
> You forgot that it is intended, there is the mantra "developers are
> expensive, hardware is cheap".
>
> --
> regards Szymon Lipiński
>