I'm making an API server that require SQL queries that has something like 20-40 lines.
I want it to be a simple server so I'm using NodeJS, express, body-parser and a database connector.
In other environments, I understand that you either use final constants or import SQL files but I don't know what's the best method in Node.
I think reading in individual SQL file for every query will be slow and since JavaScript does not support multiline string, saving them in a json object would seem tedious.
(I know ES6/Babel exists but it seems like an overkill for just one functionality).
So the question is what's the best and the most common way to store SQL queries in the context of node/express?
20-40 lines seems like a lot... Have you considered making those queries views or stored procedures?
The other thing is that if you are using at least NodeJS 4.6.1 you can use template literals out of the box
Related
I am currently creating a vb.net program in which users upload a song file to the program and then it is saved within the programs files. I have set up the actual saving of the files but would also like to store some meta data of each in a SQL database within my program.
I have looked online and although i now understand the basics of SQL, im still a little fuzzy on how you actually implement this within VB.net. I have already added the library- Imports System.Data.SqlClient but failed to work out how to begin coding in SQL.
The basics of what im trying to acheive is a if statement that will determine wether or not a SQL database has been created in a specific location, and if it hasnt it should create it.
All constructive answers appreciated, thanks.
There are a number of different database engines available. The namespace that you have chosen contains the ADO.NET client classes for Microsoft SQL Server. You would use a connection string to specify how to connect to the database. This would often contain connection information, such as server name, user name, password etc, but it sounds like you want to store data locally.
There is a local version of SQL Server called LocalDB, but I think you would still need quite a lot of the SQL Server components installed for that to work. Although you can package these with your application they may be too large for you, so you may want to look at SQL Server Compact Edition, which is much smaller and allows you to package the whole engine as part of your application and is useful for storing data locally. Compact edition doesn't have quite all of the features that LocalDB does, so you may want to compare the features available for each.
Although you can use the ADO.NET objects to connect to a database, I think most people these days would use a layer on top which transfers data back and forwards between objects in memory and the database. This also allows you to use Linq to query the database in most cases. I personally use Entity Framework. You might want to look into that. There are different ways of configuring EF so you may want to look at a tutorial. Once you have it set up, you will probably find it much easier and safer to work with than writing SQL manually though.
Im designing a UWP app that uses an SQLite database to store its information. From previous research I have blearnt that using the SQLite function SQLiteConnection.Update() and SQLiteConnetion.Insert() functions are safe to use as the inputs are sanitised before entering in the database.
The next step I need to do is sync that data with an online database - in this case SQL Server - using a service layer as my go between. Given that the data was previously sanitised by the SQLite database insert, do I still need to parameterise the object values using the service layer before they are passed to my SQL Server database?
The simple assumption says yes because, despite them being sanitised by the SQLite input, they are technically still raw strings that could have an effect on the main database if not parameterised when sending them there.
Should I just simply employ the idea of "If in doubt, parameterise" ?
I would say that you should always use SQL parameters. There are a few reasons why you should do so:
Security.
Performance. If you use parameters the reuse of execution plans could increase. For details see this article.
Reliability. It is always easier to make a mistake if you build SQL commands by concatenating strings.
When I troubleshoot a large .NET app which uses only stored procedures, I capture the sql which includes the SP name from SQL Server Profiler and then it's easy to do a global search for the SP in the source files and find the exact line which produced the SQL.
When using Entity Framework, this is not possible due to the dynamic creation of SQL statements. However there are times when I capture some problematic sql statements from production and want to know where in the code they were generated from.
I know one can have EF generate logs and tracing on demand. This probably would be taxing for a busy server and produces too much logs. I read some stuff about using mini profiler but not sure if it fits my needs as I don't have access to the production server. I do however have access to attach SQL Server Profiler to the database server.
My idea is to find a way to have EF attach/inject a unique code to the generated SQL but it doesn't affect the outcome of the SQL. I can then use it to cross reference it to the line of code which injected it into the SQL. The unique code is static which means a unique static code is used for every EF linq statement. Maybe sent as a dummy sql or a comment along with the sql statement.
I know this will add some extra traffic but in my case, it will add extra flexibility and cut a lot of troubleshooting time.
Any ideas of how to do this or any alternatives?
One very simple approach would be to execute something via ExecuteStoreCommand(): Refresh data from stored procedure. I'm not sure if you can "execute" just a comment, but at the very least you should be able to do something like:
ExecuteStoreCommand("DECLARE #MyTag VARCHAR(100) = 'some_unique_id';");
This is very simple, but you would have to find the association in two steps:
Get the SessionID (i.e. SPID) from poorly performing query in SQL Server Profiler
Search the Profiler entries for the prior SQL statement for that same SPID
Another option that might be a little more complicated but would remove that additional step when it comes to making that association is to "intercept" the commands before they get executed and inject a comment with your unique id. Please see the following S.O. Answer for details. You shouldn't need the full extent of what they did, but even if you do, it seems like all of the code (or all the relevant stuff) is there:
Adding a query hint when calling Table-Valued Function
By the way, this situation is a point in favor of using Stored Procedures instead of an ORM. And, what do you expect to be able to do in terms of performance tuning once you do find the offending app code? (another point in favor of using Stored Procedures instead of an ORM ;-).
I have doubts between two options:
Build the query in client side and send it to server.
Sending from client the needed knowledge in order to build the query in server side.
In which side I will prefer to build the query?
Advantages / Disadvantages?
Thanks.
I tend to prefer building queries on the server side and either storing them as Stored Procedures on the sql server or building the query string in a backend language like PHP.
Building the query in something like javascript and sending to the server, creates the possibility of deviants doing inline altering of your javascript and submitting the query string through something like firebug. If you build the query string in a backend (server-side) language, the only thing the user would have access to alter would be input variables (if applicable). Because of this, you should always check and cleanse all input variables for sql injection.
Removing as much access to raw code from the end user as possible seems to always be the best option, in terms of application security. Someone else may weigh-in about performance limitations; but if a user alters and submits their own query string through a javascript console and drops your entire table, performance won't really be a factor anymore will it?
I'd like to know if you could write custom functions in MongoDB similar to a stored procedure for queries?
There aren't exactly stored procedures in MongoDB, but you can write Javascript functions that get stored in the DB (in the system.js collection).
Have a look at this article to get started.
There is a special system collection named system.js that can store JavaScript functions for reuse.
NOTE:
Do not store application logic in the database. There are performance
limitations to running JavaScript inside of MongoDB. Application code
also is typically most effective when it shares version control with
the application itself.
See The Reference.