Portability

Question

Portability

Viewing 7 posts - 16 through 21 (of 21 total)

You must be logged in to reply to this topic. Login to reply

Grant Fritchey SSC Guru Points: 398882 More actions · Answer 1

I worked for one of the software vendors for healthcare products. They're out of business now. We actually had very good developers, but a CEO that thought that IT knowledge was overrated. He encouraged every sales guy, qa person, receptionist and bums from down on the corner to open up the code or the database and fix anything that they saw "broken"... I lasted nine months. I think the kicker was when one of the nurses that worked with us to determine "business" needs said "We're going to kill someone." That app was written to be portable (although we primarily ported between Paradox & SQL 6.5).

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

Roger L Reid SSCrazy Points: 2004 More actions · Answer 2

Speaking from vast experience: "it depends".

Portability is important - but you can't predict so well what that means. I have ported the same code base from - (frontend / backend)

BRL (on DEC) Unix / Britton Lee IDM -> BSD (on DEC) Unix / Britton Lee IDM -> BSD (on Pyramid) Unix / Sybase (first release, and various sucessors) -> BSD Solaris / Sybase (4.2 and succesors) -> SVR4 Solaris / Sybase 11 etc -> Y2K compatible* -> SVR4 Solaris / MS SQL Server 9

So, what's portable? Our excellent embedded QUEL/IDL needed to be AWKed into pre-standards S.Q.L. in dblib calls. Code written before SVR4 could not predict the ifdefs needed to run on SVR4. S.Q.L. standards come along and all of a sudden our S.Q.L. is not really right. Britton Lee did not allow NULLs. Sybase did, and was perfectly happy with == NULL (if you're going to insist on using NULLs, you may as well let all hell break loose). SQL Server accepts NULLs are what they are so treats them as correctly as one can - developers don't understand why a perfectly fine, standards compatable S.Q.L. statement returns fewer rows on SQL Server than Sybase - it's because the concat of the name is resulting in NULL when they have no middle initial (let's not argue whether it should be NULL or blank - it's the data that we have).

Yes, portability is important. When you can keep it generic without loosing valuable features, you should. But you can't predict what will become non-portable next week. Any time you do a platform move, you'll have a lot of work to do - so you may as well use platform specific extensions when possible.

For all that, I'm really struggling with porting databases where the developers did not follow my advice and eschew any system based sequence numbering. What a pain. You can't be totally portable, but you should do your best not to hobble yourself with really icky stuff.

For S.Q.L. portablity, the scene has changed. Once there was a horserace among the RDBM vendors. These days I can be pretty confident that S.Q.L. written to SQL Server 9 best practices will probably be like COBOL - supported forever by everyone. And if we get lucky and a better language comes along, we'll only write new stuff in it.

Meantime, I am so thankful for Perl and the DBI modules and FreeTDS - the only way to write code that talks to SQL Server and Sybase at the same time!

Roger L Reid

Miles Neale SSChampion Points: 13147 More actions · Answer 3

Portability? Probably not. I have worked in shops that are more concerned in security and protection of the assets of the company. Data and code both. In some cases where a consortium exists there is an effort to make the solution more generic, but for the most part it is the best solution.

In some shared development efforts I have assisted in making the backend more backend neutral but that has not been the rule.

I have been more concerned in the ability of the backend moving from version to version of the RDBMS rather then portability.

Not all gray hairs are Dinosaurs!

Charles Kincaid SSChampion Points: 13593 More actions · Answer 4

I spent 4 years working for a company that did J.D.Edwards development. The Edwards One World product could be housed on AS-400 (i series) machines running DB-400 or Windows machines runinng SQL Server. We had customers that had either. One customer had both.

Today I work for a different company. Our feature product runs on SQL server at the head end. Runs on Windows mobile on the client side. There are enough differences between SQL Mobile and SQL Server, even at the T-SQL level to make me think that I'm back remembering the restrictions that I had to deal with in DB-400.

I know a guy who writes on a Mac but most of his customers run on Windows. Top flight (pun intended) software too. I have software as a hobby too. I run a web site for a developer who writes in Kylix and ports each build to Delphi. The Kylix version runs on Linux and the Delphi version runs on Windows.

It may not be that important to your customers and employer, but it can do wonders for your career.

ATBCharles Kincaid

Michael Lato Ten Centuries Points: 1278 More actions · Answer 5

From an internal systems viewpoint, we write code to a specific platform (SQL Server) and have completly turned our backs on portability. We chose a platform that would work well for us - why ignore the platform-specific enhancements that improve our situation?

We did have a completely SQL-agnostic CRM application a couple of years ago. This system was so poorly written it was almost unusable - mostly in the name of portability!

Regards,
Michael Lato

Ed Hammar Ten Centuries Points: 1084 More actions · Answer 6

I've been working in the IT business since before the days when everyone and their brother were touting this new language that wasn't quite as fast as assembler but was similar in terms of speed and it was going to be portable. Some of them even claimed it would replace all other languages. The language to be the end all to portability issues and claim complete unquestioned dominance in the industry was C.

That was over 20 years ago and just as it was then it is even more so now, portability is a buzz word nothing more. It's a fantasy, if it weren't all cars would come in any color you want as long as that color is black (if you haven't heard that one google the Model T). Every language has its advantages and disadvantages and that goes for languages like C, Java, VB, Delphi, and yeah, even COBOL and FORTRAN. Just as those languages have their niches, so does database software and the languages used to develop for them.

I'm not here to claim that you can't achieve some level of portability, you can but no one in today's "gotta have it yesterday" society will accept the performance limitations of the application.

Loner SSC-Insane Points: 21279 More actions · Answer 7

In most companies I worked for only had one platform, so portability was not the issue. Unless you are talking about moving the data from the CRM system which uses JDEdwards DB2 in AS400 and our datawarehouse is using SQL Server 2000. But we can still transfer the data.

Once I worked for a software company, the software had to be able to run under VAX/VMS, IBM OS, IBM VSE, UNIX, and the file system were flat files in VAX, VSAM files and DB2 in IBM and UNIX. Talked about fun. We had IBM VSE but we did not have any data in that system, so I just moved all the codes to that system and compiled the programs and sent out to the customers and hoped they ran ok. It did.

When we created the web product, it had to run under IE and netscape. At that time we tried to use JAVA which supposed to be portable, but IE and netscape always had different interpretation of JAVA. In IE, the web page was perfect and netscape was terrible or vice versa.

For SQL server and Oracle, they supposed to use SQL but SQL Server SQL is different from Oracle SQL. PL/SQL is different from T-SQL. Just had to maintain two sets of codes.