September 1, 2016 at 12:01 pm
My definition of good enough would be significantly lower if the"we promise to fix this if it causes problems" was a firm commitment rather than an outright lie.
There's nothing like kicking yourself and being kicked by your colleagues because a "we promise to fix this..." is still generating 3am callouts 4years down the line.
I have no way of knowing how long a solution(problem) may last so "good enough" has to have some measure of an indeterminate lifespan.
Another variable is the uses to which the data is put in downstream systems and the number of those systems. If I have to nursemaid Project Turd what won't I be able to do?
How many downstream customers suffer because of faulty or late data but see me as the cause?
My worst nightmare is being held accountable for something over which I have very little control.
These aren't technical issues they are organisational and behavioural issues. Fear of the dysfunctional organisation is driving suboptimal solutions
September 1, 2016 at 1:46 pm
David.Poole (9/1/2016)
My definition of good enough would be significantly lower if the"we promise to fix this if it causes problems" was a firm commitment rather than an outright lie.There's nothing like kicking yourself and being kicked by your colleagues because a "we promise to fix this..." is still generating 3am callouts 4years down the line.
I have no way of knowing how long a solution(problem) may last so "good enough" has to have some measure of an indeterminate lifespan.
Another variable is the uses to which the data is put in downstream systems and the number of those systems. If I have to nursemaid Project Turd what won't I be able to do?
How many downstream customers suffer because of faulty or late data but see me as the cause?
My worst nightmare is being held accountable for something over which I have very little control.
These aren't technical issues they are organisational and behavioural issues. Fear of the dysfunctional organisation is driving suboptimal solutions
Well that's the thing too. We are accountable for the systems and pipelines for data. A large number of us are very defensive when it comes to things we are not as involved with, but still held accountable for when things go south such as an application being dreadfully slow because of the use of ORM. Yet, when are we responsible for making the system better for ORM as opposed to opposite?
I'm not saying that is how it should be, but I do feel it's a fair concern to raise. When do I start focusing on making the data more suited for a framework and how it interacts with my systems?
September 1, 2016 at 1:53 pm
xsevensinzx (9/1/2016)
David.Poole (9/1/2016)
My definition of good enough would be significantly lower if the"we promise to fix this if it causes problems" was a firm commitment rather than an outright lie.There's nothing like kicking yourself and being kicked by your colleagues because a "we promise to fix this..." is still generating 3am callouts 4years down the line.
I have no way of knowing how long a solution(problem) may last so "good enough" has to have some measure of an indeterminate lifespan.
Another variable is the uses to which the data is put in downstream systems and the number of those systems. If I have to nursemaid Project Turd what won't I be able to do?
How many downstream customers suffer because of faulty or late data but see me as the cause?
My worst nightmare is being held accountable for something over which I have very little control.
These aren't technical issues they are organisational and behavioural issues. Fear of the dysfunctional organisation is driving suboptimal solutions
Well that's the thing too. We are accountable for the systems and pipelines for data. A large number of us are very defensive when it comes to things we are not as involved with, but still held accountable for when things go south such as an application being dreadfully slow because of the use of ORM. Yet, when are we responsible for making the system better for ORM as opposed to opposite?
I'm not saying that is how it should be, but I do feel it's a fair concern to raise. When do I start focusing on making the data more suited for a framework and how it interacts with my systems?
That is sort of the problem; an ORM is on Object Relational Map, attempting to map on Object in the application to the appropriate Relation(s) in the database. This mapping isn't always as easy as it would seem. And trying to make the database more "object oriented" takes a way some or many of the attributes that make a relational database system a highly efficient data store capable of storing and protect a company's most valued assest, it's data.
September 1, 2016 at 2:44 pm
Lynn Pettis (9/1/2016)
xsevensinzx (9/1/2016)
David.Poole (9/1/2016)
My definition of good enough would be significantly lower if the"we promise to fix this if it causes problems" was a firm commitment rather than an outright lie.There's nothing like kicking yourself and being kicked by your colleagues because a "we promise to fix this..." is still generating 3am callouts 4years down the line.
I have no way of knowing how long a solution(problem) may last so "good enough" has to have some measure of an indeterminate lifespan.
Another variable is the uses to which the data is put in downstream systems and the number of those systems. If I have to nursemaid Project Turd what won't I be able to do?
How many downstream customers suffer because of faulty or late data but see me as the cause?
My worst nightmare is being held accountable for something over which I have very little control.
These aren't technical issues they are organisational and behavioural issues. Fear of the dysfunctional organisation is driving suboptimal solutions
Well that's the thing too. We are accountable for the systems and pipelines for data. A large number of us are very defensive when it comes to things we are not as involved with, but still held accountable for when things go south such as an application being dreadfully slow because of the use of ORM. Yet, when are we responsible for making the system better for ORM as opposed to opposite?
I'm not saying that is how it should be, but I do feel it's a fair concern to raise. When do I start focusing on making the data more suited for a framework and how it interacts with my systems?
That is sort of the problem; an ORM is on Object Relational Map, attempting to map on Object in the application to the appropriate Relation(s) in the database. This mapping isn't always as easy as it would seem. And trying to make the database more "object oriented" takes a way some or many of the attributes that make a relational database system a highly efficient data store capable of storing and protect a company's most valued assest, it's data.
Ultimately as long as you're supporting the company the best you can there's not much more you can do especially when you have to interact with platforms that aren't designed for relational databases, if it ends up being an issue you can blame the other platform with a clear conscience 🙂
I totally get why things like EAV seem awesome to programmers they just suck in databases. Or having to deal with mainframe record structures, wait SQL Server has a limit on the number of columns per table what a stupid restriction?
September 1, 2016 at 3:03 pm
ZZartin (9/1/2016)
Lynn Pettis (9/1/2016)
xsevensinzx (9/1/2016)
David.Poole (9/1/2016)
My definition of good enough would be significantly lower if the"we promise to fix this if it causes problems" was a firm commitment rather than an outright lie.There's nothing like kicking yourself and being kicked by your colleagues because a "we promise to fix this..." is still generating 3am callouts 4years down the line.
I have no way of knowing how long a solution(problem) may last so "good enough" has to have some measure of an indeterminate lifespan.
Another variable is the uses to which the data is put in downstream systems and the number of those systems. If I have to nursemaid Project Turd what won't I be able to do?
How many downstream customers suffer because of faulty or late data but see me as the cause?
My worst nightmare is being held accountable for something over which I have very little control.
These aren't technical issues they are organisational and behavioural issues. Fear of the dysfunctional organisation is driving suboptimal solutions
Well that's the thing too. We are accountable for the systems and pipelines for data. A large number of us are very defensive when it comes to things we are not as involved with, but still held accountable for when things go south such as an application being dreadfully slow because of the use of ORM. Yet, when are we responsible for making the system better for ORM as opposed to opposite?
I'm not saying that is how it should be, but I do feel it's a fair concern to raise. When do I start focusing on making the data more suited for a framework and how it interacts with my systems?
That is sort of the problem; an ORM is on Object Relational Map, attempting to map on Object in the application to the appropriate Relation(s) in the database. This mapping isn't always as easy as it would seem. And trying to make the database more "object oriented" takes a way some or many of the attributes that make a relational database system a highly efficient data store capable of storing and protect a company's most valued assest, it's data.
Ultimately as long as you're supporting the company the best you can there's not much more you can do especially when you have to interact with platforms that aren't designed for relational databases, if it ends up being an issue you can blame the other platform with a clear conscience 🙂
I totally get why things like EAV seem awesome to programmers they just suck in databases. Or having to deal with mainframe record structures, wait SQL Server has a limit on the number of columns per table what a stupid restriction?
Actually EAV has some very valid reasons in the database world. As an entire structure it is hideous but for some things it is WAY better than a standard relational table set. For things like object properties it is nearly indispensable. A real example might be user profiles in a system that is customizable. This allows for adding new user properties that the developer never considered at design time. Leveraging EAV like this is seamless with no additional development needed and if you fill your properties in dotnet code the performance is screaming fast. As with everything in sql server it can be over used or used in the wrong situations. But when used rationally it is sometimes the best tool for the job.
As for column limits....well the actual limit is so absurdly high that if you hit that max with mainframe files there are far bigger issues than the imposed max number of columns. It is still 1,024 afaik which is a ridiculous amount of data points for any system no matter how denormalized. And of course if you can use sparse columns you can extend that all the way out to 30,000.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
September 2, 2016 at 12:01 am
Bad design and coding practices always seem to challenge system limits. I don't see why SQL Server should be any different.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 2, 2016 at 12:32 am
I can remember when vb.net came out. I was in a development role at the time and two of my colleagues had honours degrees in software engineering. Very bright people.
One of them came in proclaiming that .net was going to kill off the cowboy coders!
The reason frameworks exist is to abstract low level tasks and reduce the opportunity for bugs. Unfortunately they are attempting to reduce the infinite.
I'm at least cheered to know that this isn't purely an IT thing. YouTube is full of fails and Darwin awards that are just as bad, but much more entertaining
September 2, 2016 at 7:07 am
David.Poole (9/2/2016)
I can remember when vb.net came out. I was in a development role at the time and two of my colleagues had honours degrees in software engineering. Very bright people.One of them came in proclaiming that .net was going to kill off the cowboy coders!
The reason frameworks exist is to abstract low level tasks and reduce the opportunity for bugs. Unfortunately they are attempting to reduce the infinite.
I'm at least cheered to know that this isn't purely an IT thing. YouTube is full of fails and Darwin awards that are just as bad, but much more entertaining
Well, things are a bit different from then and now. I use SQLAlchemy in Python and it's pretty powerful in the sense, I have a lot of control to meet the needs of both the DBA and the developer. Here is just a quote to summarize that feature.
The library takes on the job of automating redundant tasks while the developer remains in control of how the database is organized and how SQL is constructed. Built to conform to what DBAs demand, including the ability to swap out generated SQL with hand-optimized statements, full usage of bind parameters for all literal values, fully transactionalized and batched database writes using the Unit of Work pattern. All object-relational patterns are designed around the usage of proper referential integrity, and foreign keys are an integral part of its usage.
Viewing 8 posts - 136 through 142 (of 142 total)
You must be logged in to reply to this topic. Login to reply