Yeah but your already paying for a developer ... On Wed, May 4, 2016 at 2:36 PM, Szymon Lipiński <mabew...@gmail.com> wrote:
> > > On 4 May 2016 at 20:20, Will McCormick <wmccorm...@gmail.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 <mabew...@gmail.com> >> wrote: >> >>> >>> >>> On 4 May 2016 at 19:09, Will McCormick <wmccorm...@gmail.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 <mabew...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On 4 May 2016 at 18:14, Will McCormick <wmccorm...@gmail.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 <u...@oss4u.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 >
