October 2, 2015 at 9:40 am
We have one system where the core DB has been around since 1965. It serves its purpose very well. Mainframe applications can be very long lived, and seldom need to be changed to handle new technology. IBM has been very good about making new systems backwards compatible.
One in house built system I support has been around since 2000 with no real changes in the DB other than to add tables for new functionality. Front end has gone from VB6 to web based. The core stored procedures are still used, since the business rules haven't changed in 15 years.
The accounting system I support has the same table names and intrinsic design that started in Revelation G in 1986, and was then ported to SQL Server from Advanced Revelation in 1998
Much of the core data for SAP is stored in tables that have been around since at least the early 90's
Very few systems only last a couple of years.
October 2, 2015 at 10:15 am
No less than 18 years old, including some no-longer-used stored procedures that could only have worked on SQL Server 7.0 or earlier.
Personally, I prefer to treat "short-term bandaid" solutions as full production solutions; once the immediate need isn't so urgent, all plans to "correct it later" after "getting something up RIGHT NOW" are put off, downgraded in priority, and eventually sent to the retirement home to wait out their days without so much as an annual visitor to talk to.
October 2, 2015 at 10:16 am
I believe we have systems built over 15 years ago, however the average age we seem to achieve is 10-12 years. Sometimes being under development is not especially positive - one we are now quoting to replace is creaking because features have been added then removed then added again, modified to meet new requirements, this will be 12 years old. You can never get them quite clean again when that happens.
October 2, 2015 at 10:26 am
In the mid '90s I wrote a blockwatch grant tracking system in Access, I left that org in 2001. Two years ago I went to have lunch with my former co-workers and the guy who ran the system said that they're still using it. I would imagine they upgraded it as that would have been Office 95 or 97. I don't remember anything about it except it had some cool conditional logic for reporting to handle the weirdness of grants. Still, very cool to know it's still running. I'd kinda like to see it again and dig in to the code to see what it was like and likely how horribly I wrote it. 😛
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
October 2, 2015 at 11:02 am
Our oldest are as old as the company, but that's only 1999. They will still be here in 10 years, no question.
October 2, 2015 at 11:04 am
I've been working on our main production database for over five years now. It's housed on a Sql Server 2005 instance so the thing is at least 7 or 8 years old. It was scaled up from Access a while before that so this thing is nigh unto 10 - 15 years old as a whole.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
October 2, 2015 at 11:27 am
The database that I maintain in my company started as an Access database sometime in the mid to late 90's. It was transitioned over to SQL 2000, SQL 2005, and SQL2008 (and due for another upgrade soon I hope!). This database supports a very large custom coded ERP application (written in VB6 still!) and both the database and the application are still being maintained and developed against.
October 2, 2015 at 11:35 am
The one I've mentioned before, which I don't work on anymore but still exists, is the SQL Server 2000 database running in 6.5 compatibility mode, with a Visual C++ 6.0 front end, running a very important system for a very important financial institution.
October 2, 2015 at 11:36 am
The core of our factory manufacturing system is 18 years old (from a vendor) and it is being phased out next year and will run on a completely different data model. Until recently it was running on windows nt and sql server 6.5 :-D. 18 years for a manufacturing control system is well onto the long tail of the curve, so we think we came out ahead on that. We have a lims/mes/wms system that originated in ms access and has been running on sql server since 2003. It is continually expanded and improved, but the core architecture is unchanged. There's no reason to think it won't serve us well forever, really. I am proud of that one.
October 2, 2015 at 11:43 am
A database originally designed with a de-normalized data model and crappy SQL back in the 90's could easily be lumbering along today as is after having been ported to v2000, v2008, and now v2014. Upgrading to a newer version of SQL Server is not the same thing as re-architecting.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 2, 2015 at 11:44 am
My oldest was stared in dBase II, then migrated to FoxBASE then migrated to Sybase SQL Server then migrated to MS SQL Server. I first touched it in 1984 and became 'in charge' in 1987 and passed on 'control' in 1995, but it is still in use essentially the same base structure today. It did exist for about 3 years before I started working on it - so 'it' is about 34 years old, but it was only 31 years ago that it became something that I would call 'mine'. AND if you want ... it was heavily based on a previous design on a mini-computer that went back another 10 years. So 31 or 34 or 44 years depending on your way of thinking of it.
And several significant 'base' structures in it I am using essentially unchanged in a new project that we started working on this week, so those pieces will be going forward I expect at least another 10 or 20 years - hopefully more.
I believe that, other than quick and dirty projects that had a fixed time life, about 85% of the projects I have ever been involved in continue to be used fundamentally the same as the original design, so, I have some for almost every age from 31 years to 1 day old.
Good design spans technologies and time.
October 2, 2015 at 12:13 pm
We have one database that started on SQL 6.5 so about 15 years, now on SQL 2008. Also Access DB that was on Access 2.0 in 1998 when I took over. I've upgraded it to Access 2013 now, still works.
Good maintenance keeps things ticking.
October 2, 2015 at 12:28 pm
I think you hit the nail on the head. When a schema is designed in a scalable and normalized way - the extension to handle new requirements becomes a natural progression and you do not need to start over from scratch every time something new comes up. Obviously if the use-case and requirements change dramatically you may find a need for a new design - but if the requirements are substantially the same, a well thought out data model and schema will stand the test of time and will grow as needed.
I support a few healthcare related applications that were written well over 20 years ago starting as Microsoft Access databases and later growing into SQL-2012. The user "tactics" of indexing, etc. have evolved to leverage the additional capabilities of SQL, and of course the user interaction has changed dramatically over the years - but the underlying data model was complete, logical, and scalable. It was good then and is just as good today.
October 2, 2015 at 1:45 pm
I am personally working on a database that predates my current employment of 15 years. It's a SQL Server that has been maintained for what looks like 18 years or more...
October 3, 2015 at 4:28 am
Having read through this thread the observation I would make is that where a data model is a good expression of the business process it has been designed to support, particularly where that business process is core to the business then longevity is to be expected.
At their heart the core business might not change that much over the decades. I know of a system running in Clipper that costs next to nothing to maintain but delivers a 7 figure sum in profits every year.
The problem comes not from the software design but the underlying technology. When it eventually breaks who has the knowledge to reinstall or fix it? I'd hate to have to recover a SQL6.5 DB server or ensure that the depending apps were working correctly.
The other thing that strikes me is that these ancient systems date back to a time when hardware components were a minute fraction of what is considered minimum spec today and yet they are still fit for purpose! This tells me that core business systems don't require much technology resource. Somewhere a huge percentage of the available power is being bled off
Viewing 15 posts - 16 through 30 (of 61 total)
You must be logged in to reply to this topic. Login to reply