January 26, 2015 at 10:02 am
mike.gallamore (1/26/2015)
Or applications that sit on top of someone else's database: say health care systems, CRM etc. Often it becomes the job of the front end guys to quickly re-wire their application when the users want a new version of the main system and the schema changes all over the place. At my work my team are both the db and the webservice guys. Another team handles UI (and we support a few different products that hit our database). Becomes a bit of a pain negotiating between teams when you want to refactor things but better than becoming a javascript monkey 😉
Admittedly, JavaScript is not everyone's cup of tea; it's not a fully-objectified language, and it can be challenging to support and debug. But I think it's uncalled-for to denigrate those who work with it.
January 26, 2015 at 10:44 am
Usually I'm the odd one out. It's comforting to know that I have been taking the reasonable course the whole time. The database is the foundation and the application has to live on top of it.
The application is bothered by extra columns? As an application guy I can't quite see why that would happen with a database. With flat files or something like that I can see how something like that could be a problem.
Once I was caught by the SELECT * and then take the (x) column by number. Database changes at one client had been deployed in a different order and so new columns were not in the same order as other clients even at the same deployment level.
Deploying the database changes ahead of the application changes just makes good sense. The exceptions to this would be when data is moved. The change to the database then breaks the old application version.
ATBCharles Kincaid
January 26, 2015 at 11:26 am
Hey, it's 2015; the developer should code the application first, and then with a few clicks of the mouse they can auto-generate all the database junk in the background for us. Our role as the DBA is simply swapping out backups and performance tuning.
Right? :crazy:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 26, 2015 at 12:34 pm
Eric M Russell (1/26/2015)
Hey, it's 2015; the developer should code the application first, and then with a few clicks of the mouse they can auto-generate all the database junk in the background for us. Our role as the DBA is simply swapping out backups and performance tuning.Right? :crazy:
Eric! I laughed so hard that I almost fell out of the chair. With arm restraints and a seat belt that's not so easy.
For subsidiary Access data stores I had an object that I would pass a manifest of table name, column name, and data type. The object would compare that to the database and generate ALTER TABLE scripts to add missing columns and even whole tables.
ATBCharles Kincaid
January 26, 2015 at 12:59 pm
Charles Kincaid (1/26/2015)
Eric M Russell (1/26/2015)
Hey, it's 2015; the developer should code the application first, and then with a few clicks of the mouse they can auto-generate all the database junk in the background for us. Our role as the DBA is simply swapping out backups and performance tuning.Right? :crazy:
Eric! I laughed so hard that I almost fell out of the chair. With arm restraints and a seat belt that's not so easy.
For subsidiary Access data stores I had an object that I would pass a manifest of table name, column name, and data type. The object would compare that to the database and generate ALTER TABLE scripts to add missing columns and even whole tables.
Here is my attempt at an emoticon blowin dope smoke.
:Whistling::discuss:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 26, 2015 at 2:29 pm
mike.gallamore (1/26/2015)
Or applications that sit on top of someone else's database: say health care systems, CRM etc. Often it becomes the job of the front end guys to quickly re-wire their application when the users want a new version of the main system and the schema changes all over the place. At my work my team are both the db and the webservice guys. Another team handles UI (and we support a few different products that hit our database). Becomes a bit of a pain negotiating between teams when you want to refactor things but better than becoming a javascript monkey 😉
Use lots of views here.
January 26, 2015 at 3:13 pm
Eric M Russell (1/26/2015)
So, deploying a new procedure, table, or column days or weeks before the associated application change is deployed? Yes, that happens all the time in my universe where the database development and application development teams are seperate. The database comes before the application, both for the initial deployment and change request deployments.
Good to hear. Don't hear many people doing it.
January 26, 2015 at 3:29 pm
Steve Jones - SSC Editor (1/26/2015)
Eric M Russell (1/26/2015)
So, deploying a new procedure, table, or column days or weeks before the associated application change is deployed? Yes, that happens all the time in my universe where the database development and application development teams are seperate. The database comes before the application, both for the initial deployment and change request deployments.Good to hear. Don't hear many people doing it.
Well, they're just making their lives difficult for no reason. If the application and database changes are deployed in tandem, and the application deployment has to be rolled back, then does that mean the related database deployment has to be rolled back too? I don't want to do that unless it's absolutely necessary. The way I see it, the database, ETL, and application(s) are seperate systems that communicate using a contract. The goal of the database developer is not to break that contract, which shouldn't occur simply because a new procedure or column has been added.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 11, 2015 at 6:53 am
GoofyGuy (1/26/2015)
I think it's possible in many cases to upgrade a database over time by carefully planning your schema changes and accounting for those changes in your front end architecture.If the front-end architecture exclusively consumes web services (rather than performing database I/O calls), the web services often may abstract out changes in the underlying database schema. The planning then centres on ensuring correct alignment between the database schema and related web services.
But the web services are still just client applications as far as the RDBMS is concerned.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 11, 2015 at 7:02 am
One key issue that kept cropping up in my mind when reading this thread was that there was a lot of assuming that there is a single application for a single database. I have often found this not to be the case. As such you must always code against named columns making no assumption that there will not be others.
Also, you can map the name to a column index when accessing the first row then access via the dynamically calculated index if performance is a key issue.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 11, 2015 at 8:28 am
Gary Varga (2/11/2015)
One key issue that kept cropping up in my mind when reading this thread was that there was a lot of assuming that there is a single application for a single database. I have often found this not to be the case. As such you must always code against named columns making no assumption that there will not be others.Also, you can map the name to a column index when accessing the first row then access via the dynamically calculated index if performance is a key issue.
Absolutely. Especially now as we find data moving, and a second "application" might be a warehouse or some reporting system.
February 11, 2015 at 9:50 am
But the web services are still just client applications as far as the RDBMS is concerned.
But not a business application, per se. One advantage of using web services, rather than making direct SQL calls in a business application, is that the application may not have to reflect schema changes.
February 11, 2015 at 9:56 am
GoofyGuy (2/11/2015)
But the web services are still just client applications as far as the RDBMS is concerned.But not a business application, per se. One advantage of using web services, rather than making direct SQL calls in a business application, is that the application may not have to reflect schema changes.
I was talking from a technical client viewpoint.
My point is that when they are both client applications they both will have to change if their interface of the RDBMS changes (be it a stored procedure, view or a table).
An application that calls a web service is not a client application of the RDBMS.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 11, 2015 at 10:01 am
I was talking from a technical client viewpoint.
Yes, so I understood, Gaz! We tend to see the world through our own coloured set of glasses; I'm a business application development manager, so my remarks were directed that particular way.
February 11, 2015 at 10:04 am
GoofyGuy (2/11/2015)
I was talking from a technical client viewpoint.Yes, so I understood, Gaz! We tend to see the world through our own coloured set of glasses; I'm a business application development manager, so my remarks were directed that particular way.
OK. It felt like an editorial on a technical aspect of our roles. Blindsided? Moi? Maybe!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 16 through 30 (of 47 total)
You must be logged in to reply to this topic. Login to reply