This is probably very basic stuff. I want to create a table if a certain condition is met. Basically I have a db with a version number, and if the version is as expected, a new table is created.
This is pretty straightforward to do, say, in python, but is there a pure SQL way, or then a pure SQLite way, of doing this? Basically I want to know if my update scripts could be free of any other programming langage other than SQL (or SQLite's SQL).
I looked at the CASE clause but it seems I can't use it as a top-level switch statement.
No, there's no way to do this. SQLite has no flow control statements and the only if condition you can specify on the CREATE TABLE command is IF NOT EXISTS.
You will have to use a scripting language to execute this logic.
Related
In my current liquibase project I usually use plain SQL to create tables, because I believe it gives better control over the DDL syntax, and I can paste exactly what I modeled. Of course I'm losing the automatic rollback functionality, but except that - are there any other benefits of using createTable elements over plain SQL?
I thought it has some advantages when you switch to a different database server, but even in this case I would probably just create a different version of the SQL manually (again, for better control over the DDL syntax).
I'm coding with Solar2d in Lua and I wanted to pick data from an SQL table.
So I was thinking to use the sqlite3 plugin, but it's unclear how to use it.
Yes, Solar2D has built-in SQLite library.
Check the documentation here.
To pick data use SELECT with db:nrows(sqlcommand)
(sorry - the question wasn't originally clear. I'm not looking for the fastest ways to build insert, delete statements etc, but the fastest way to build queries to alter, for example, tables in the database e.g. adding or removing a column)
So, what's the fastest and best way to build database alteration queries in SQL server? I'm going down the manual route of writing the SQL as it's given me the best result in the past with the IBM Informix database. Points to note:
I've found that using the table designer in management studio is a poor method (in my experience this is too simplistic and GUI driven to be of use, and often requires tables to be completely rebuilt to work well)
The query designer only allows simple select, update delete etc. queries to be built
Any recommended tools that make this easier?
Am I missing something about the SQL management studio that I should know? Seems to create overly complex SQL for building a table, that's difficult to comprehend and edit
Do you write Java, .Net, Python or code by hand? What's the difference with SQL?
If there are patterns and code generation can be automated, (write and) use a code generator (but that goes for the other languages I listed too).
SQL is a lot more than just SELECT ... WHERE ... or UPDATE ... SET ... WHERE id = value.
for most kinds of scripts, I ask SMS to generate the initial script (create, drop, alter, select, insert, delete, execute, etc), and then tweak to taste. not sure if this is sufficient to your needs, but I find it useful
to generate scripts, Right click an object (table/view/sproc/fn/etc) and expand "Script ".
hope that helps.
Hi
I am building a database of users where each user has some normal details stored about them.
I would also like to store which languages the user knows.
I know that one way to do this would be to create a language table and then create a separate table that maps between languages and users. Would it be easier to use the SQL "set" type instead of creating an extra table for languages?
Probably not. There are lots of problems with using SET (only 64 elements, for example; and I'm pretty sure there are more than 64 languages).
As a general rule, if you can enumerate all the possible/supported languages/values, SET will work. Otherwise I'd use the table, because going back and ALTER TABLEing to add a new language isn't a very good way to do things and will also probably require changes to the application(s) using the SET, whereas if you use a separate table it should Just Work to INSERT a new language row.
And, language being what it is, I'd not want to assume I know every language beforehand.
Here's an argument for SPs that I haven't heard. Flamers, be gentle with the down tick,
Since there is overhead associated with each trip to the database server, I would suggest that a POSSIBLE reason for placing your SQL in SPs over embedded code is that you are more insulated to change without taking a performance hit.
For example. Let's say you need to perform Query A that returns a scalar integer.
Then, later, the requirements change and you decide that it the results of the scalar is > x that then, and only then, you need to perform another query. If you performed the first query in a SP, you could easily check the result of the first query and conditionally execute the 2nd SQL in the same SP.
How would you do this efficiently in embedded SQL w/o perform a separate query or an unnecessary query?
Here's an example:
--This SP may return 1 or two queries.
SELECT #CustCount = COUNT(*) FROM CUSTOMER
IF #CustCount > 10
SELECT * FROM PRODUCT
Can this/what is the best way to do this in embedded SQL?
A very persuasive article
SQL and stored procedures will be there for the duration of your data.
Client languages come and go, and you'll have to re-implement your embedded SQL every time.
In the example you provide, the time saved is sending a single scalar value and a single follow-up query over the wire. This is insignificant in any reasonable scenario. That's not to say there might not be other valid performance reasons to use SPs; just that this isn't such a reason.
I would generally never put business logic in SP's, I like them to be in my native language of choice outside the database. The only time I agree SPs are better is when there is a lot of data movement that don't need to come out of the db.
So to aswer your question, I'd rather have two queries in my code than embed that in a SP, in my view I am trading a small performance hit for something a lot more clear.
How would you do this efficiently in
embedded SQL w/o perform a separate
query or an unnecessary query?
Depends on the database you are using. In SQL Server, this is a simple CASE statement.
Perhaps include the WHERE clause in that sproc:
WHERE (all your regular conditions)
AND myScalar > myThreshold
Lately I prefer to not use SPs (Except when uber complexity arises where a proc would just be better...or CLR would be better). I have been using the Repository pattern with LINQ to SQL where my query is written in my data layer in a strongly typed LINQ expression. The key here is that the query is strongly typed which means when I refactor I am refactoring properties of a class that is directly generated from the database table (which makes changes from the DB carried all the way forward super easy and accurate). While my SQL is generated for me and sent to the server I still have the option of sticking to DRY principles as the repository pattern allows me to break things down into their smallest component. I do have the issue that I might make a trip to the server and based on the results of query I may find that I need to make another trip to the server. I don't worry about this up front. If I find later that it becomes an issue then I may refactor that code into something more performant. The over all key here is that there is no one magic bullet. I tend to work on greenfield applications which allows this method of development to be most efficient for me.
Benefits of SPs:
Performance (are precompiled)
Easy to change (without compiling the application)
SQL set based features make very easy doing really difficult data tasks
Drawbacks:
Depend heavily on the database engine used
Makes deployment of upgrades a little harder (you have to deploy the App + the scripts)
My 2 cents...
About your example, it can be done like this:
select * from products where (select count(*) from customers>10)