Java or C#: which has higher compatibility?

This is a discussion on Java or C#: which has higher compatibility? within the General Discussions forums, part of the Community Boards category; Originally Posted by bithub Usually when SQL is formatted this way, the format string will fit on one line, and ...

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,256
    Quote Originally Posted by bithub
    Usually when SQL is formatted this way, the format string will fit on one line, and then you place the variables on the following lines. This removes the need to split up the SQL string at all.
    I typically use prepared statements with an API similiar to the kind of string formatting that you demonstrated, and in my experience it is not exactly typical (though neither it is atypical) for the SQL statement to be able to fit on a single line even then (presumably your mileage varies with recommended/enforced line widths).

    Quote Originally Posted by bithub
    Of course if you have a monstrosity of a SQL statement, it still may take multiple lines. In that case though, why in the world are you not using stored procedures instead?
    Because the database software (in my case, SQLite) does not support them. There may be other reasons when using database software designed to compete with Oracle rather than fopen(), considering that Mario F. mentioned something about "those cases where the DDL is meant to go inside the code".

    By the way, have we had this discussion before? I have a sense of deja vu.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #17
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,255
    presumably your mileage varies with recommended/enforced line widths).
    Are you one of those 80 character max coders?

    Because the database software (in my case, SQLite) does not support them.
    In that case prepared statements are the way to go (which you already know). Java pretty much sucks when it comes to using SQLite though. I've found that Derby is a pretty good alternative though.

    By the way, have we had this discussion before? I have a sense of deja vu.
    I'm sure it's come up before, but I don't remember having it. My memory is not what it used to be though...

  3. #18
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,575
    Quote Originally Posted by bithub View Post
    Are you one of those 80 character max coders?
    Ah, but you really don't want to do maintenance on single line SQL statements running much longer than that. Especially when they start involving such things as joins or, god forbid, subqueries.

    In that case prepared statements are the way to go (which you already know)
    I don't see how, really. You will still have to build the query inside the code.

    But also, rarely I've seen in real life the benefits of prepared statements. Not saying there are none. But being that there's hardly a thing I develop that doesn't include a database, I can't fail to notice I can't remember a single time when I used one anywhere...

    The issue with prepared statements is that odd principle behind them that makes it only useful if you run the query multiple times. But... isn't this exactly what you usually don't want to do? I mean, the moment I create a query that needs to go inside a loop, I really messed up somewhere in my design. Badly.

    You can argue they become useful in multi-user environment. But here I'd prefer stored procedures(1), since I just saved the network one server round-trip per call, which can be quite significant on the usually heavily jammed business LANs. Oh, and stored procedures are cached with their query plan, which is not often the case with prepared statements.

    Finally, because I don't want to leave anything behind , there's also the problem that with a preparared statement you are actually introducing into your design a state method. But often the case is you are "prohibited" from doing that either because you are bound by the coding practices in place in your working environment to only create stateless methods for database connections, or because you know damn well it's just horrid to not close a connection you opened when you don't need it anymore.

    --

    (1) Not always depending on circumstances. I remember one case where I was required to keep all business logic restricted to the application tier. And even when I was not required to do so, I tended to be very conservative on SPs. If the business environment doesn't seem to favor them, I sure as hell won't be the one introducing it. I always found SPs nice for performance reasons. But fishy, because I'm moving business logic to the database.
    Last edited by Mario F.; 07-21-2009 at 06:10 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #19
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,256
    Quote Originally Posted by Mario F.
    But also, rarely I've seen in real life the benefits of prepared statements. Not saying there are none. But being that there's hardly a thing I develop that doesn't include a database, I can't fail to notice I can't remember a single time when I used one anywhere...
    One real life benefit is as an escaping mechanism: if you are going to build the SQL statement in code, then there is the risk of SQL injection. Prepared statements allow you to separate the SQL statement from the data it uses, and this tends to be a safer approach than using an escaping function on the data due to its uniformity.

    Quote Originally Posted by Mario F.
    The issue with prepared statements is that odd principle behind them that makes it only useful if you run the query multiple times. But... isn't this exactly what you usually don't want to do? I mean, the moment I create a query that needs to go inside a loop, I really messed up somewhere in my design. Badly.
    I think that it depends on the situation. Thinking of a case where you want to display a huge scrollable list of items to the user, you might prefer to only display a small part of the list, then reuse the prepared statement when the user starts scrolling instead of caching the entire list for display.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #20
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,575
    Quote Originally Posted by laserlight View Post
    One real life benefit is as an escaping mechanism: if you are going to build the SQL statement in code, then there is the risk of SQL injection. Prepared statements allow you to separate the SQL statement from the data it uses, and this tends to be a safer approach than using an escaping function on the data due to its uniformity.
    Not sure if I follow the last statement, laserlight. I do tend to favor parsing my variables for other reasons other than escaping characters, since it saves an unnecessary round-trip to the server in case the input is not valid.

    However, mind you, I'd agree the escaping mechanism in place for prepared statements (I had to check on the JDBC's one since I didn't know about that particular one) is useful. But I look at it more as a nicety. The decision of using or not using prepared statements should be based on its actual purpose.

    I think that it depends on the situation. Thinking of a case where you want to display a huge scrollable list of items to the user, you might prefer to only display a small part of the list, then reuse the prepared statement when the user starts scrolling instead of caching the entire list for display.
    It's a good point. Particularly because the alternative of using datasets (on those programming engines that support it) is really nothing much more than a prepared statement with an interface to go... so you can honestly say I lied and I did use prepared statements before

    I did face situations like you describe and where I didn't have access to full-blow datasets. Just recently with my current home-made project. But I don't count SQLite in my arguments because prepared statements are pretty much the SQLite way since 3.0.

    I never used JDBC (or Java for that matter) beyond an initial curiosity to the programming language. But In any case, in the context of a programming engine that offers both prepared and unprepared statements and I'm not allowed to use stored procedures, I'd probably go with prepared statements yes, on an case like you describe.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #21
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Enough posts that I don't want to quote

    Prepared statements do have their place and there are certainly times when doing a query in a loop might be the way to go. For example, when you need to do a query using the results of a previous query. Now, a lot of times you can do a subquery to get the same results but:
    1. It can make the query really complex
    2. Which can make it hard to understand
    3. And take a long time to execute


    So it becomes a kind of trade off.

    Building a query in code is pretty common when you have different pieces that might or might not be included. While that could be handled by separately written queries it can easily get unmanageable. Think about if you had three parts to a complex query that might or might not be present, you'd have to write 8 different queries to handle the possible inclusions.

    Since I deal mostly in loosely typed languages I actually like the following system:
    Code:
    $result = db_query("
    	SELECT item.name, item.cost, stock.quantity
    	FROM (items AS item, locations AS location)
    	JOIN stock ON (stock.id_item = item.id_item
    		AND stock.id_location = location.id_location)
    	WHERE item.name='{string:itemname}'
    		AND location.name='{string:locationame}'",
    	array(
    		'itemname' => 'Mt Dew',
    		'locationame' => 'Fridge',
    	)
    );
    The function itself does the type checking, escapes the strings, etc. Added benefit is that by reading the query alone you know what the replacements represent and what their types are suppose to be.

  7. #22
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Plus, if you're using Oracle you can store Java :-)

  8. #23
    and the hat of copycat stevesmithx's Avatar
    Join Date
    Sep 2007
    Posts
    506
    Quote Originally Posted by zacs7 View Post
    Plus, if you're using Oracle you can store Java :-)
    Huh?
    Not everything that can be counted counts, and not everything that counts can be counted
    - Albert Einstein.


    No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes.
    - Herbert Mayer

  9. #24
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,575
    Quote Originally Posted by stevesmithx View Post
    Huh?
    You can store java classes as Oracle schema objects. You do this by using the loadjava utility or the Oracle SQL statement CREATE JAVA. Meanwhile, Oracle includes similar functionality to java's classpath to handle dependencies. After you publish the class with CREATE PROCEDURE [...] AS LANGUAGE JAVA, you can then call the class from within PL/SQL with a simple CALL statement.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  10. #25
    Registered User
    Join Date
    Sep 2008
    Posts
    47
    I did both C# and Java with data access and I really love java, and its much more portable still. You can't run C# on a mainframe, you can run java though. Can you even run .net on *nix?
    Last edited by mr_coffee; 07-27-2009 at 02:14 AM.

  11. #26
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yes, with Mono. But Mono is always playing catch-up to MS's .Net.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Mats, the java answers
    By Jaqui in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 04-22-2008, 03:12 AM
  2. C#, Java, C++
    By incognito in forum A Brief History of Cprogramming.com
    Replies: 10
    Last Post: 10-05-2004, 03:06 PM
  3. The Java language is being expanded
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 26
    Last Post: 06-11-2004, 10:07 PM
  4. Java woes
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 07-06-2003, 01:37 AM
  5. How to use Java with C++
    By Arrow Mk 84 in forum C++ Programming
    Replies: 2
    Last Post: 02-27-2003, 04:12 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21