Results 1 to 6 of 6

Thread: SQL 2 Java

  1. #1
    Join Date
    Jan 2013
    Posts
    35

    Unanswered: SQL 2 Java

    Hi dear Reader,
    I have a question:
    What is your opinion about converting SPs to another language for example Java?
    I need to do this because there is a tool that will help me a lot and it only works with Java.

    Thanks

  2. #2
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    User written stored procedures are easy to change. In general it is easier to change any given stored procedure to a .NET based language than it is to change it to Java, but in most cases "code is code" and the functionality can be recoded using almost any language.

    If this question is related to your previous question about system stored procedures, then a whole different set of issues apply. System stored procedures are called from each other and sometimes from within the SQL Server Engine itself, as well as being called from applications. Trying to cope with that degree of complexity would be mind-boggling! I would emphatically recommend against trying to port the system stored procedures anywhere, any way , any time. This is dangerous!

    Moving user written stored procedures to another language/server is essentially introducing an Application Server into your environment. This is nearly always a good idea for many reasons if the application architecture will support it.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  3. #3
    Join Date
    Jan 2013
    Posts
    35
    Thanks,
    I should say you have answered all the questions that could pop up related to this thread.

  4. #4
    Join Date
    Jan 2013
    Posts
    354
    Provided Answers: 1
    What is your opinion about converting SPs to another language for example Java?
    I really hate it. A database is for data; it persists data, it maintains the data integrity, handles access to the data, retrieves the data and (like all good code) should be easy for the next poor bastard to maintain.

    It does not format reports, perform statistical or mathematical computations, handle network protocols, etc. The idea of any tiered architecture is that each tier is loosely coupled to the others and has high cohesion.

    There are 40+ CLR languages that can be embedded in T-SQL. As the "current poor bastard" how many of them can you maintain? Why will the "next poor bastard" be any better than you? Did you do that last Java upgrade and re-compile everything? Regression testing?

    None of the CLR languages can be used by the optimizer, but SQL can. None of them are meant to be used in a set-oriented environment. They push you back to record by record processing. The languages have different rules for rounding or even basic functions (remember the Pascal MOD() debate?).

    What we want is a DB tier that has a DML statement "thrown over the wall" to it, does its magic and throws an answer back in a well-defined, application neutral package.

    These days, I do not even like sorting the data if I can help it. When I pass a result set to a report server, it does the all sorting for a dozen reports all at once.

  5. #5
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Quote Originally Posted by Celko View Post
    I really hate it.
    Methinks thou hast missed a memo, sir Celko!

    They actually WANT to move the stored procedures onto a whole different platform, i.e. an application server. Unless I'm really corn-fused about what you'd like to see, I think that this idea would make you deliriously happy!

    My point was that if they also want to move the system stored procedures (provided as part of the database, and therefore behind your "wall"), that they were travelling uncharted waters! I'm not saying that it would be impossible, but I'm sure that I don't want to be the one to have to do or maintain it!

    Joe, relax a bit... We're on your side!

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  6. #6
    Join Date
    Jan 2013
    Posts
    35
    Quote Originally Posted by Celko View Post
    I really hate it. A database is for data; it persists data, it maintains the data integrity, handles access to the data, retrieves the data.
    I agree with you and should say that this operation is needed for another purpose and the DB will still do what its meant to do, so don't be

    Thanks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •