I've been working on SQL though I do not have enough knowledge on database. But still since last 1 week, I've been learning PL/SQL. I covered few basic things like how to write code, variable, different blocks etc. But my main confusion is, where should I use PL/SQL or where PL/SQL is basically used in industry ?
I'll be great full to all of you if any one give me a proper response.
I am assuming you have some understanding of when you use SQL, and you are asking where PL/SQL comes into the equation.
SQL is a declarative syntax - code what you want and let the database figure out how to fulfill it. As long as the what is a set.
PL/SQL is the procedural syntax - code exactly how you want to fulfill what. And the what doesn't have to be a set; it can be anything like any procedural language (e.g., python, java, c#, etc.) The main difference between PL/SQL and those other procedural languages is that the database is the compiler and executor of the resulting compiled code. It's an intimate way to couple data access code and your database.
I hope that helps.
Related
I am building a system in Scala for feature engineering where the end user API receives aggregations on list of objects/events.
For example, a client of this tool might pass into it a function that given an array of past pageviews for a specific web user, filters for the ones coming from a specify country and count them. The output of this call will then be a number.
It can be thought as a very simple reduce operation.
I am figuring out how to build the API for such system. I could write a simple custom language to perform counts and filters but I am sure that it is not the best approach, especially because it will not be expressive enough, unless designed with care.
Are you aware of something like an expression language that could be used to express simple functions without the need for me to build one from scratch?
The other option would be to allow end users to pass custom code to this library, which might be dangerous at runtime.
I am aware of apache Calcite to plug SQL into different data structures and db. It is a good option, however it forces me to think in "columnar" sql way, while here I am looking more for something row based, similar to the map-reduce way of programming.
You mention Apache Calcite, but did you know that you can use it without writing SQL? If you use Calcite's RelBuilder class you can build algebra directly, which is very similar to the algebraic approach of MapReduce. See algebra in Calcite for more details.
I would like to know Why we need to compile the program of progress 4GL? Really what is happening behind there? Why we are getting .r file after compiled the program? When we check the syntax if its correct then we will get one message box 'Syntax is correct' how its finding the errors and showing the messages.Any explanations welcome and appreciated.
Benefits of compiled r-code include:
Syntax checking
Faster execution (r-code executes faster)
Security (r-code is not "human readable" and tampering with it will likely be noticed)
Licensing (r-code runtime licenses are much less expensive)
For "how its finding the errors and showing the messages" -- at a high level it is like any compiler. It evaluates the provided source against a syntax tree and lets you know when you violate the rules. Compiler design and construction is a fairly advanced topic that probably isn't going to fit into a simple SO question -- but if you had something more specific that could stand on its own as a question someone might be able to help.
The short answer is that when you compile, you're translating your program to a language the machine understands. You're asking two different questions here, so let me give you a simple answer to the first: you don't NEED to compile if you're the only one using the program, for example. But in order to have your program optimized (since it's already at the machine language level) and guarantee no one is messing with your logic, we compile the code and usually don't allow regular users to access the source code.
The second question, how does the syntax checker work, I believe it would be better for you to Google and choose some articles to read about compilers. They're complex, but in a nutshell what they do is take what Progress expects as full, operational commands, and compare to what you do. For example, if you do a
Find first customer where customer.active = yes no-error.
Progress will check if customer is a table, if customer.active is a field in that table, if it's the logical type, since you are filtering if it is yes, and if your whole conditions can be translated to one single true or false Boolean value. It goes on to check if you specified a lock (and default to shared if you haven't, like in my example, which is a no-no, by the way), what happens if there are multiple records (since I said first, then get just the first one) and finally what happens if it fails. If you check the find statement, there are more options to customize it, and the compiler will simply compare your use of the statement to what Progress can have for it. And collect all errors if it can't. That's why sometimes compilers will give you generic messages. Since they don't know what you're trying to do, all they can do is tell you what's basically wrong with what you wrote.
Hope this helps you understand.
In PL-SQL, there are some fancy new concepts, like table functions, objects, and probably others I have not discovered yet.
But then again, there is also plain simple code generation (dynamic pl-sql) that you can "execute immediately".
These can help with code reuse.
From what I can tell, table functions and objects can help with creating modular code, but still not enough to remove the entire of it (maybe I am not using the best of them; I have to admit my objects only contain data for now and no logic).
On the other side, the code generating is much more simple, and can reduce duplicate code more. But it is kind of hard to read what the actual business is behind the code generation logic.
I want modular and not-duplicate code. Should I stick with plain code generation? What are some pros and cons of each?
Dynamic SQL is generally better than advanced PL/SQL features like table functions, object-relational types, data cartridge, the ANY* types, etc. With a few simple tips you can avoid the pitfalls of dynamic SQL and use it to create modular systems.
Advanced PL/SQL features are cool, and at some point you'll have to use them at least a little. They're great for solving weird, specific problems. But you will almost certainly regret creating an Oracle system that is centered around one of those features. I've wasted weeks or months of my life on each of the above PL/SQL features.
Dynamic SQL
Pro - It always works. It might be painful, but there's always a way to make it work in SQL and make it run fast.
Con - A little harder to read and write.
Advanced PL/SQL
Pro - Cool features, elegant code that can perfectly solve certain problems.
Con - Will let you down at a critical moment.
It's hard to give examples of advanced PL/SQL failures without writing a novel. The stories typically go something like this: "We combined features A, B, C ... we hit bugs X, Y, Z ... everyone got angry ... we spent a month re-writing it."
Dynamic SQL doesn't have to be so bad. It just takes some discipline.
Good formatting and instrumenting. Make sure the dynamic SQL looks beautiful and it can be easily printed out for debugging. Follow good programming practices - indent, add comments, use meaningful names, etc. It will be a shock to the point-and-click programmers when the "Beautifier" button on the IDE doesn't help them. Don't let anyone get away with sloppy code - just because it's technically a string shouldn't allow anybody to avoid common style rules.
Alternative quoting mechanism. Use the q syntax to avoid constantly escaping things. For example, q'[I'll use single quotes if I want to!]' instead of 'I''ll use single quotes if I want to!'.
Templates instead of concatenation. Write the code in un-interrupted blocks and then replace the dynamic parts later. Combine it with the q strings to avoid a million quotation marks and pipes in the code. For example:
v_dynamic_sql_template constant varchar2(32767) :=
q'[
select a, b, $DYNAMIC_SELECT_LIST$
from table1
$DYNAMIC_JOIN_1$
where table1.a > 1
$DYNAMIC_WHERE_1$
]';
...
v_dyanmic_sql := replace(v_dynamic_sql_template, '$DYNAMIC_SELECT_LIST$', v_variable);
...
(In this question I assume you are an intermediate or advanced Oracle developer. If you're a beginner, the answer is probably static SQL statements but you haven't
seen enough SQL features to realize that yet.)
Using SQLite in a memory-constrained embedded system with a fixed set of queries, it seems that code and data savings could be made if the queries could be 'pre-prepared'. That is, the prepared statement is produced by (an equivalent of) sqlite3_prepare_v2() at build time, and only _bind(), _step() etc need to be called at runtime, referencing one or more sqlite3_stmt* pointers that are effectively static data. The entire SQL parsing (and query planning?) engine could be eliminated from the target.
I realise that there is considerable complexity hidden behind the sqlite3_stmt* pointer, and that this is highly unlikely to be practical with the current sqlite3 implementation - but is the concept feasible?
This was discussed on the SQLite-users mailing list in 2006. At that time D. Richard Hipp supported a commercial version of SQLite that ran compiled statements on a stripped down target, which did not have any SQL parser. Perhaps you could check with hwaci to see if this product is still available.
I'm watching some lecture's on Functional Programming and the main 'data structure' so to say, but there really isn't one in FP, is lists, so my question is: when one deals a lot with database's and 'lists' of data, then is Functional Programming not superior to OOP?
One of the biggest improvements in reading from databases in recent years is LINQ. LINQ is actually based a lot on functional programming principles. In fact SQL is also a very functional style language.
I see no problems with reading data from a database using a functional language.
Now modifying the database... that's a different story. I'll leave that for another day. :)
Well, Lisp deals with lists, but the lists are heterogenous, and can well represent a tree. Other languages, like Haskell, give you structured types, named and unnamed, and - in contrast to lisp - allow for static type checking.
One thing that pure functional languages do not have is the notion of stateful variables that can be assigned. Some Lisp implementations provide such state - you get a setq opeator -, while Haskell doesn't. Reading and writing databases, however, is all about having state - and lots of it, that's what databases are for - and about reading from and writing into it. So, operating on a database is quite the opposite of using a functional language.
It does, however, make sense to create a database query language which expresses the DB operations in a non-imperative, but in a declarative, and hence in a functional way. That's how SQL makes sense, and that's also how the way LINQ is defined makes sense.
So, it makes sense to have a database language which is functional, but it's not because of the lists.