Oracle vs Sequel - question [message #642744] |
Thu, 17 September 2015 20:47 ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](//www.gravatar.com/avatar/be09d55a3ff354fbec06ae44ee77d67f?s=64&d=mm&r=g) |
poconosms1
Messages: 4 Registered: September 2015 Location: New Jersey
|
Junior Member |
|
|
Hi All,
I could use some help/advice. I am not a programmer, but am the project manager/owner of an application currently written in Oracle 9i using MS visual 2003, frame 1.x and .net. My company has all the licenses to take it to 12c ms visual2013, and frame 4.2. There's probably a million lines of code, and hundreds of stored procedures, views, and triggers. My development site is already 11g and it would take 3 months to upgrade production. I have 500 users and the data base is over 20 gigs with photo storage and retrieval. The application has FileNet storage.
My IT department is suggesting that I should have the database converted to Sequel 2015 and moved to a virtual environment. They are asking me for 300k to do this. I suspect it will cost closer to 700-900k because of all the proprietary rewrite required to go from Oracle to Sequel. The IT department would hire outside consultants to do the work, specifically since our in house shop lacks experience in Sequel. Currently our in house programmers update and program new modules.
To me it's a no brainer to keep it in oracle, since my company already has all the licenses. In addition, the in house programmers are not familiar with sequel database programming, so once the consultants leave I don't think i'll have the proper support. The IT group's line is there will be documentation to follow.
The current programmers and DBAs are unofficially warning me not to convert to sequel.
Thoughts?
|
|
|
Re: Oracle vs Sequel - question [message #642747 is a reply to message #642744] |
Fri, 18 September 2015 02:35 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
gazzag
Messages: 1119 Registered: November 2010 Location: Bedwas, UK
|
Senior Member |
|
|
What is the relationship of the head of your IT department with these "consultants" who are going to cost you an alleged $300K? As you say, this figure is likely to balloon substantially during the project and I don't see what you stand to gain. As you say, you already have the licences in place to simply upgrade what you have. That, in itself, will be quite enough of an undertaking!
|
|
|
Re: Oracle vs Sequel - question [message #642750 is a reply to message #642747] |
Fri, 18 September 2015 03:14 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
cookiemonster
Messages: 13965 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
Sounds like madness.
If all the sql was written in the app layer swapping over would be relatively easy - though there would still be quite a bit of work needed in all likely hood. Even if everything worked out of the box you'd probably need to do changes for performance reasons due to differences in how oracle and sql sever work.
But since you've got all that code in the DB the amount of work involved is going to be huge. T-SQL and PL/SQL really aren't equivalent, they have fundamentally different approaches to a lot of things and you can't do a straight conversion from one to the other. In a lot cases you will need to work out what the PL/SQL is supposed to do and write the T-SQL from scratch based on the functional design without reference to the existing code.
Coupled with the fact that your people don't know sql-server and it's hard to see any upside, never mind sufficient upside to outweigh the negatives.
Also it's entirely possible to run oracle in virtual environments if you want, I've got some dev servers set up that way.
Seriously - what does the IT dept think the upside to this is?
|
|
|
|
Re: Oracle vs Sequel - question [message #642752 is a reply to message #642751] |
Fri, 18 September 2015 03:29 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
cookiemonster
Messages: 13965 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
And just to hammer that point home - it means that a bit of t-sql code and a bit of pl/sql that appear to be functionally equivalent can give different results if not designed by someone who really truly understands the differences in the locking scheme and transaction processing between the two.
|
|
|
|
|
|
|
|
|
|
|
Re: Oracle vs Sequel - question [message #642780 is a reply to message #642744] |
Sat, 19 September 2015 02:17 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
John Watson
Messages: 8965 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
On the face of it, the move to SQL Server (whih I assume is what you mean by "Sequel"?) doesn't sound sensible. But on a second reading, perhaps it is. The database is tiny (only 20GB) and the application is not large (only 400 tables). Furthermore, you are using FileNet. FileNet is now an incredibly powerful ECM, is your FileNet release as old as your 9i DB? Dating back to before IBM bought it? If your application is just some sort of interface to FileNet, the conversion might be really simple if you take advantage of the current capabiities. Perhaps most of your code isn't really needed any more.
|
|
|
|
Re: Oracle vs Sequel - question [message #642823 is a reply to message #642786] |
Mon, 21 September 2015 02:57 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) |
cookiemonster
Messages: 13965 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
As far as I can see the size of the DB, number of tables and amount of data doesn't really matter. Creating copies of all the tables and shipping the data over is relatively simple.
The problem remains the amount of code to be converted, the fact that the oracle and sql server work differently at a fundamental level and the lack of sql server knowledge amongst your team.
|
|
|