Is there any database technology comparable to the SQL CLR?
Specifically, one that allows me to code high-performance routines in a common programming language like C# with shared memory (e.g. static variables) that can be called directly from within an SQL statement?
Not really.
More specifics about what you are trying to achieve would help.
There may be a flaw in your design / approach.
If you need to code high-performance, functional routines, they should probably not be embedded in your database. You should be implementing a middle-tier and placing your routines there instead.
Related
Recently I have read (in a PDF document - SQL for dummies) that SQL is actually a data sublanguage and not a programming language like C++ or Java or C# and right now I am a bit confused, because since you can develop things through SQL, I thought it is similar to other programming languages.
Could anyone explain to me what is the difference? Thanks
Try to write a simple but non-trivial application using nothing but standard SQL that asks the user to input their name, and outputs "Hello, ."
Maybe you could do it with some vendor-specific extensions, but then it wouldn't be standard SQL.
SQL is designed to be a domain-specific language for database queries. It's meant to be used in combination with a more fully-featured language. The SQL standard defines ways that you can write lines of SQL within the code file of C, C++ or other languages. There's no standard way to write a full standalone app using just SQL.
Read the standard. The SQL/PSM part defines a full-blown programming language with loops and IF-THEN-ELSE and what have you. SQL/PSM was initially amended to the existing standard in 1996 and formally included in SQL:1999.
As Bill Karwin hinted at, SQL does not have features for UI interaction, but then the very same thing is true about the java language (no, the swing package is not part of the language), and the COBOL language, and the ALGOL language, and many many others.
SQL began life as a data sublanguage. That history is >20yrs behind us. (The "data sublanguage" portion is still the most-used and most-useful part, but that does not change the fact that technically speaking, SQL-the-language has everything it takes to be regarded as a full-blown programming language.)
According to wikipedia a sublanguage
the term "sublanguage", first used for this purpose by E. F. Codd in 1970, refers to a computer language used to define or manipulate the structure and contents of a relational database management system (RDBMS). Typical sublanguages associated with modern RDBMS's are QBE (Query by Example) and SQL (Structured Query Language).
that means that sublanguages cannot be used to develop a standalone applications but they could be incorporated with other computer programming languages to manage the application-database interaction.
Standard SQL can only be used for defining database schemas and for querying and updating data. Database vendors have extensions to SQL (like Microsoft's T-SQL) that are full-blown programming languages.
I am working on implementing a Relational Database Management System for a school project. The system generates pseudo-SQL commands based on what the user enters into an interactive system. These commands are passed through a parser, which translates the line into actual function calls that the engine can execute.
I feel like I understand fairly well the operations that the database needs to perform in an SQL sense, but I'm unsure of how to translate those tasks to a procedural language that can actually carry out those operations.
I'm trying to find one or more examples of a relational algebra system implemented in an object oriented language like C++ or Java, so I can get an idea of what might work for my design. If anyone has an example they can share with me, that would be greatly appreciated. It doesn't need to be super complicated (in fact I would prefer the opposite), I am just trying to get an idea of how I might translate operations like selection or projection into an actual programming language.
Take a look at SIRA_PRISE - a "Straightforward Implementation of a Relational Algebra - Prototype of a Relational Information Storage Engine".
I suppose this isn't a particularly "good fit for our Q&A format" but no idea where else to ask it.
Why is SQL-querying text based? Is there a historical motivation, or just laziness?
mysqli_query("SELECT * FROM users WHERE Name=$name");
It opens up an incredible number of stupid mistakes like above, encouraging SQL injection. It's basically exec for SQL, and exec'ing code, especially dynamically generated, is widely discouraged.
Plus, to be honest, prepared statements seem like just a verbose workaround.
Why don't we have a more object-oriented, noninjectable way of doing it, like having a directly-accessible database object with certain methods:
$DB->setDB("mysite");
$table='users';
$col='username';
$DB->selectWhereEquals($table,$col,$name);
Which the database itself natively implements, completely eliminating all resemblance to exec and nullifying the entire basis of SQL injection.
Culminating in the real question, is there any database framework that does anything like this?
Why are programming languages text-based? Quite simply: because text can be used to represent powerful human-readable/editable DSLs (Domain-specific language), such as SQL.
The better (?) question is: Why do programmers refuse to use placeholders?
Modern database providers (e.g. ADO.NET, PDO) support placeholders and an appropriate range of database adapters1. Programmers who fail to take advantage of this support only have themselves to blame.
Besides ubiquitous support for placeholders in direct database providers, there are also many different APIs available including:
"Fluent database libraries"; these generally map an AST, such as LINQ, onto a dynamically generated SQL query and take care of the details such as correctly using placeholders.
A wide variety of ORMs; may or may not include a fluent API.
Primitive CRUD wrappers as found in the Android SQLite API, which looks suspiciously similar to the proposal.
I love the power of SQL and almost none of the queries I write can be expressed in such a trivial API. Even LINQ, which is a powerful provider, can sometimes get in my way (although the prudent use of Views helps).
1 Even though SQL is text-based (and such is used to pass the shape of the query to the back-end), bound data need not be included in-line, which is where the issue of SQL Injection (being able to change the shape of the query) comes in. The database adapter can, and does if it is smart enough, use the API exposed by the target database. In the case of SQL Server this amounts to sending the data separately [via RPC] and for SQLite this means creating and binding separate prepared-statement objects.
So, I haven't had any luck finding any articles or forum posts that have explained to me how exactly a query language works in conjunction with a general use programming language like c++ or vb. So I guess it wont hurt to ask >.<
Basically, I've been having a hard time understanding what the roles of the query language are ( we'll use SQL as an example for query language and VB6 for norm language) if i'm creating a simple database query that fills a table with normal information (first name, last name, address etc). I somewhat know the steps in setting up a program like this using ado objects for the connection and whatnot, but how do we decide which language of the 2 gets used for certain things ? Does vb6 specifically handle the basics like loops, if else's, declarations of your vars, and SQL specifically handles things like connecting to the database and doing the searching, filtering and sorting ? Is it possible to do certain general use vb6 actions (loops or conditionals) in SQL syntax instead ? Any help would be GREATLY appreciated.
SQL is a language to query a database. SQL is an ISO standard and relational database vendors implement to the ISO standard and then add on their own customizations. For example in SQL Server it is called T-SQL and in Oracle it is called PL-SQL. They both implement ISO standards and so each will have identical queries for a simple select like
select columname from tablename where columnname=1
However, each have different syntax for string functions, date functions, etc....
The ISO SQL standard by design is not a full procedural language with looping, subroutines, ect as in a full procedural language like VB.
However, each vendor has added capabilities to their version to add some of this functionality in.
For example both T-SQL and PL-SQL can "loop" through records using various constructs in their language.
There is also a difference when working with data that many developers are not well in tuned with. That is set based operations vs. procedural based.
Databases can work with procedural constructs but are often more performant with set based. A developer who is not versed in this concept may end up creating a very innefficient query. Here's an example of this discussion.
With any situation you have to weight out the pro's/con's of where it is best to do this work.
I tend to favor using procedural constructs such as loops in the language I am using over SQL. I find it easier to maintain and the language I am using offers more powerful syntax for me to get the job done.
However, I keep both options as a tool in the toolbox. For example, I have written data conversion scripts in SQL and in this case I have used the looping constructs in SQL.
Usually programming language are executed in the client side (app server too), and query languages are executed in the db server, so in the end it depends where you want to put all the work. Sometimes you can put lot of work in the client side by doing all the calculations with the programming language and other times you want to use more the db server and you end up using the query language or even better tsql/psql or whatever.
Relational databases are designed to manage data. In particular, they provide an efficient mechanism for managing memory, disk, and processors for large quantities of data. In addition, relational databases can handle multiple clients, guarantee transactional integrity, security, backups, persistence, and numerous other functions.
In general, if you are using an RDBMS with another language, you want to design the data structure first and then think about the API (applications programming interface) between the two. This is particularly true when you have an app/server relationship.
For a "simple" type of application, which uses a lot of data but with minimal or batch changes to it, you want to move as much of the processing into the database as is reasonable. Here are things you do not want to do:
Use queries to load things into arrays, and then do array manipulations at the language level. SQL provides joins for this.
Load data into an array and do manipulations and summaries on the array. SQL provides aggregations for this.
Save data into a file to have a backup. Databases provide backup mechanisms.
If you data fits into an array or on an Excel spreadsheet, it is often sufficient to get started with the data stored there. Only when you start to expand the needs (multiple clients, security, integration with other data) do the advantages of a database become more apparent.
These are just for guidance and to give you some ideas.
In terms of doing what where, do as much as is sensible in SQL (given it runs on a server) as you can.
So for instance don't do stuff like this (psuedo code)
foreach(row in "Select * from Orders")
if (row[CustomerID] = 876)
Display(row)
Do
foreach(row in "Select * from Orders where CustomerId = 876")
Display(row)
First it's likely Orders is indexed by CustomerID so it will find all 876s order way quicker.
Second to do the first one you just sucked every record in that table into the client's memory space probably across your network.
What language is used is essentially irrelevant, you could invent your own DBMS with it's own language.
It's where you do what processing that matters. It's Rule with exceptions, but the essential idea is let your backend do as much as it can.
I am looking for information on the best practices or project layout for software that uses SQL embedded inside VB.NET or C#. The software will connect to a full SQL DB. The software was written in VB6 and ported to VB.NET, we want to update it to use .NET functionality but I am not sure where to start with my research. We are using Visual Studio 2005. All database manipulations are done from VB.
Update: To clarify. We are currently using SqlConnection, SqlDataAdapter, SqlDataReader to connect to the database. What I mean by embed is that the SQL stored procedures are scripted inside our VB code and then run on the db. All of our tables, stored procs, views, etc are all manipulated in the VB code. The layout of our code is quite messy. I am looking for a better architecture or pattern that we can use to organize our code.
Can you recommend any books, webpages, topics that I can google, etc to help me better understand the best way for us to do this.
I am looking for a better architecture or pattern that we can use to organize our code
...
topics that I can google
Take a look at DAL (Data Access Layer) for database transactions
Here is a link to a StackOverflow question posted by someone who is facing a similar situation
Creating a Class Library in VB.NET
When you google "How to create DAL", you will see list of how to create a DAL as well as what DAL is.
And here is a nice article that shows how DAL fits into an N-Tier achitecture
What is n-Tier Architecture?
Webopedia: N-Tier Application Architecture - Shows a nice graphical representation
It sounds like you're looking for a grand theoretical book that is written for one very specific case, i.e. what is the best practice for managing our current spaghetti SQL code framework, and I don't know that I've ever seen a book or document that describes that.
That being said, we converted several applications from VB6 to C# a few years back and were in the same place. Other than breaking apart certain modules so that their organization made more logical sense overall, our applications are essentially the same as they were, just rewritten in C#. I don't personally like the idea of separating SQL code from the function for which it was written (which is sort of what it sounds like you're trying to do); in general, if we have a function that needs to hit the database, we create a SqlCommand and, optionally, a SqlDataReader, set the CommandType to StoredProcedure and add the parameters, then perform the call and consume the result, doing with it whatever the function was programmed to do.
I don't know that that is the best way to do it, but it works for us.
Would it be possible to convert it to using LINQ? It's safer than converting it to using regular old embedded SQL statements.
In addition to what Sung Meister said, you should also consider moving the SQL from the VB.NET code into Stored Procedures, and then call the SPs from the VB.NET code (the Data Access Layer). It provides many advantages.