For example, the original SP include several IN parameters and SQLs. Now, I used java application which implemented each SQLs and used Oozie to simulate the whole process/workflow in Oracle SP, not sure if it is the right way. Could you please provide some advices?
Thanks in advance!
You can use CTE (Common Table Expressions) to model your queries. Stored procedures as database objects are not supported in Hive/Impala yet. You may want to have a look here
Related
I mainly want to use advantage to be able to access Fox tables larger than 2 gig. My programs are simple and are run from the command window.
I have Adv Data Archetect installed and have the ODBC driver installed.
I'm not very knowledgeable with connections, etc.
Can someone explain to me, provide a link or provide the code that I would need to be able to use and create 2 gig + tables.
Thanks
I cannot tell from the OP what you have actually done, but it sounds like you are expecting to be able to use an ODBC driver with an existing Visual FoxPro application without changing the application from the direct table access. That is not possible.
Here is a link to a screencast showing an example of using ODBC to get to a table that is over the 2GB limit. If I recall correctly, it shows how to use views to access the data; doing it that way can minimize the number of changes you need to make. More information about remote views can be found here.
You can also use ODBC "directly" with SQL pass through statements. It is also possible to use OLE DB with cursor adapters if you prefer that over ODBC.
hi all
We do know that CommandType property of a SqlCommand object has 3 options: TableDirect, Text and StoredProcedure or "SP".
Knowing that "SP" has benefits over two other options, my question is do you make lots of SP in your own systems?
Or What solution do you have instead of creating SP?
Thank you
Aside of creating Stored Procedures you can use Object Relational Mapping
Such as:
linq to sql
Nhibernate
Entity Framework
Data Access :SP's vs ORMs
Choose the best way that suits you.
In all production system I used SPs and pure ADO.NET Core to access the data. Systems range from having 100-300 tables and about 500-1000 stored procedures.
Most of the Data Access code is generated using a tool. I've posted the source code and sample application on my blog if you're interested in using/modifying it. The tool can generate over 100,000 lines of code in about 20-25 seconds going against a database with about 750 stored procedures.
Data Access Layer - Code Gen
Of course if you're no familiar with Databases, data modeling/design and stored procedures you're probably better off using Linq to SQL or EF4 (Entity Framework version 4) or similar. If you need brute force performance then ADO.NET core along with Stored procedures is the way to go.
Re: your first question
When you go down the path of stored procedures, the number of stored procedures begins to grow continually for the life of the project. Outside of the basic CRUD operations, each stored procedure tends to be tightly bound to a particular problem and not very re-usable. A rule of thumb is that I can expect 8-12 stored procedures for each data table (excluding reference or code tables, such as the list of states or countries).
The very large number of procs makes naming conventions very important so that you can find anything without constantly visually re-scanning the whole list of 400-500 procs.
Re: your second question
There are a lot of ugly things that happen with sql written inside of strings inside of C# or VB.NET -- it's error prone, ugly, etc.
Linq, nHybernate and many others exist, but the "concept count" (the number of things you need to learn to start being productive), is much higher than learning how to write a good stored procedure executer in C#.
I try to make sure that stored procedures are only created for database functionality - not business logic.
It's Database Functionality when I have some database architecture that's a bit obscure and I want to hide that from callers.
It's Business Logic when it is simply the way in which my application adds or updates or how much validation they do, etc., etc.
I'm developing a Java EE application (JSF + Richfaces + Oracle 10g), and i wanted to use JPA.
But in the end, i didn't see any advantages of using it, because it's going to complexify my code.
I found that calling my procedures (stored procedures in my orale DB) is better than using JPA (because i can, for example, change some lines in those procedures without the need to re'compile my "WAR" project every time i have some error + i can use PL/SQL which helps me a lot)
So, i wanted to ask you people, when to use JPA ?
Isn't making your own queries (you can choose the right ordering for you selects, the columns that you want to select, and not all the columns: because of ORM and the fact that your entities attributes are mapped to the columns of your table, and that oblige you to select all the attributes present in your entity,....)
Is it my method that i used (stored function)
But in the end, i didn't see any advantages of using it, because it's going to complexify my code.
This might be subjective but, personally, I find JDBC typically more verbose, harder to maintain and thus somehow more complex. With an ORM like JPA, you don't have to write all the CRUD queries, you don't have to handle the mapping of query results to objects, you don't have to handle the low level stuff yourself, etc.
I found that calling my procedures (stored procedures in my orale DB) is better than using JPA (because i can, for example, change some lines in those procedures without the need to re'compile my "WAR" project every time i have some error + I can use PL/SQL which helps me a lot)
This is totally dependent on your definition of "better". In your case, you might prefer SP because of your development workflow (I don't run my code in container to setup the persistence part) and because you are comfortable with PL/SQL. But again, personally, I don't find SP "better":
I don't really enjoy hand writing SQL queries for everything
I find that SP are harder to test, debug, maintain
I find that SP are bad for code reuse
I find that SP lock you in (I consider this as a disadvantage)
I tend to find systems build around SP harder to scale
Read also Who Needs Stored Procedures, Anyways? (amongst other resource) for more opinions.
So, I wanted to ask you people, when to use JPA ?
When you want to speed-up development, to focus on implementing business code instead of plumbing. And of course, when appropriate.
Isn't making your own queries (...)
Did you identify a particular performance problem? Or are you just assuming there will be a problem. To my experience, retrieving more columns than required is most of time not an issue. And if it becomes an issue, there are solutions.
You can define what fields are retrieved in a query, using JPA.
Why is the complexity of your code going up with use of JPA ? You state no example. Before you'd have to do messy JDBC, and now you just call "em.persist(obj)" ... is that really more complex.
You ought to be thinking in terms of what relations there are between objects (if any) and that be the determiner on whether you need an ORM
In this OLE DB msdn example, (yes, it is dated 1997, but still works :)) I'm wondering what the historic point of OLE DB was if you still apparently wrote SQL to interact with the underlying datasource.
The one thing I'm thinking is if the ICommandText was not executed directly on the database, but instead somehow interpretted by OLE DB then passed off as a vendor specific SQL command/command to manipulate underlying datasource in format it understands. Is that true?
The intent of OLE DB technology is to have a generalized way to connect, work with transactions, and work with datasets. But you still have to write SQL queries. Remember, the intent of the SQL language was to have a generic language for querying data (but, as you've seen, certain parts of the language are platform-dependent). How you connect and how you query are mutually exclusive.
And, yes, the CommandText is executed directly in the database.
Perhaps you want something a level up such as NHibernate, Subsonic, Entity Framework, etc.?
I can vouch for the fact that there is NO translation done by OLE DB.
If you have different databases, you would have to provide different SQL statements based on the vendor. Always fun with dates and Oracle vs. MS databases...
With newer versions of DB2 you can write stored procedures in SQL or you can create procedures in Java (or other languages) that can then be added to the database and called just like SQL procedures. I'm wondering what the the pros and cons of each method are. I'm specifically interested in comparing those two types of procedures, not debating procedures versus external code which I think has already been covered. Here is what I've come up with so far:
SQL:
Better performance for basic SQL functionality
Less verbose for simple logic, i.e. you can run SQL directly
No extra compile step - just create procedure ...
Java:
More structured and full-featured code (classes, objects, reuse, libraries)
Better resources for help both in terms of programmers and documentation
Any other thoughts?
Not just Java but any procedural language: procedural, that's the key.
DB2 is a relational algebra, not a programming language. If you need to do something complex, it's better to use a procedural language than try to bend SQL into something it's not meant to be.
We actually use REXX for our DB2/z work but I've seen guys here use bash on the mainframe for quick prototyping. Some who only use SQL create all these horrible temporary tables for storing things that are best kept in structures and away from the DB.
My thoughts are that complexity is the only differentiating factor between using SQL directly in a stored procedure and a procedural approach. We have two rules of thumb when making these decisions.
1/ If a unit of work requires more than two trips to the database, we make it a stored procedure.
2/ If a stored procedures creates a temporary table, then we use a procedural language to do it.
You may already have found this but just in case and for any others that swing by here there's an IBM Redbook on SProcs and the changes for DB2 v9 available at
DB2 9 for z/OS Stored Procedures: Through the CALL and Beyond
which discusses the available options and their relative merits.
The advantage with the SQL stored procedures is they are portable to other Db2 UDb with minimal or no changes. But Db2 external procedures would be a better choice as you can do more with a procedural language than sql alone.
I would say cobol would be a better fit for DB2 external stored procedures than Java for the below reasons.
1). You would be able to reuse some code from existing programs. Converting a cobol sub program to a stored procedure or stored procedure to a cobol sub program is very easy to accomplish.
2). You would be able to use existing cobol development team who has functional knowledge with the system.