I'm building asp.net mvc app, and I want to know the ramifications of me switching from sqlserver2008 to mysql?
Apart from some syntax tweaks, what other things should I am taking into consideration (technically speaking ofcourse) if I want to move over to use mysql?
convert sprocs to inline queries
transaction and locking maybe handled differently
others?
There are some differences with how the two treat some kinds of locking and concurrency, etc. but for 95% of web applications those kinds of issues simply never come into play. If you're doing standard CRUD, maybe some transactions, executing a few stored procedures? No difference to speak of except the syntax, a good reference to which can be found here.
I really recommend checking out DbLinq, which is based on LINQ to SQL but supports lots of different SQL databases. It gets us much closer to making applications truly db-agnostic - you can swap out the SQL Server provider for MySQL, PostgreSQL, Oracle, Firebird, SQLite, Ingres - and all the LINQ expressions stay exactly the same. No need to tweak any queries.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I m using ASP.NET Core 1.0 and website will be big (expecting about 5,000 visitors per hour). I have read many times that stored procedures are very fast and safe (in terms of SQL injection etc). But the code first EF if so easy that I want to use it, but the CRUD methods are hidden.
What will be the disadvantages (if any) to use Scaffolding with EF over SP's in terms of performance and security?
As long as you are using parameterized SQL you should be okay in terms of SQL injection. Never use user input to directly "build" SQL queries via string concatenation. So, as long as you use Entity Framework, stored procedures, or other tools correctly you shouldn't have to worry about SQL injection.
In terms of performance Entity Framework and other similar tools do perform worse overall. I'm not sure that alone is enough to keep you from using it though unless your program expects to have very heavy usage.
Stack Exchange has a nice open source tool Dapper is more lightweight than Entity but still has some nice features. It allows you to write raw SQL. See the section on performance in the Dapper readme. It performs very well, much better than other frameworks.
Staying away from stored procedures can help improve your architecture. Stored procedures may encourage you to encode lots of business logic in the database where unit and integration testing is more difficult to do. Also, deploying new apps becomes more difficult due to having to keep your application, stored procedures, and schema in sync.
So, in short Entity Framework is a great tool but can decrease performance. There are alternatives to stored procedures that are still high performing. Security shouldn't be an issue with whatever mature tool you use (correctly).
Edit to answer additional questions
Isn't Dapper susceptible to SQL injection?
Sure, but just about any tool is if used incorrectly. Here is the proper way to use Dapper example from their documentation. This query is parameterized.
connection.Execute(#"insert MyTable(colA, colB) values (#a, #b)",
new[] { new { a=1, b=1 }, new { a=2, b=2 }, new { a=3, b=3 } }
)
Now, here is a bad example that is susceptible to SQL injection:
connection.Execute(#"insert MyTable(colA, colB) values ('" + a + "', '" + b + "')")
Is Entity Framework always safe?
No, if you concatenate variables like the previous section and use ExecuteQuery you run into issues as well.
Are stored procedures always safe?
No, you can still run into SQL injection issues if you use dynamic SQL without parameterization.
Here is a link that discusses how ORMs and stored procedures are susceptible to SQL injection: http://www.troyhunt.com/2012/12/stored-procedures-and-orms-wont-save.html
What will be the disadvantages (if any) to use Scaffolding with EF over SP's in terms of performance and security?
No security issues if used properly like discussed above. Scaffolding is great if you're doing CRUD pages.
If you need to do advanced reporting you may need custom SQL which can still be done with Entity Framework. There is nothing wrong with using scaffolding for as much of your app as it makes sense to use it for and then use parameterized SQL via Entity for everything else. You can always even use scaffolding and then modify the generated classes to do what you want. For CRUD pages use scaffolding and for advanced queries write your own.
The performance hit from using Entity Framework for simple queries probably won't hurt you for basic queries - it should be minimal. You need to worry more about proper indexing and database schema most likely. A bad schema or incorrect indexing will cause performance issues in a hurry.
I like to think of choice between writing stored procedures and writing queries in EF as similar (in some way) to difference between programming in assembler and writing programs that are being runned in managed environment (like .NET and Java). Applications written for managed environments are always slower than those written in assembly language, but on the other hand it is usually much easier (and thus cheaper) to write complex applications using managed languages. With use of EF linq you will write your queries much faster and they will be usually simpler than their sql equivalents and thus easier to maintain. Other important factor is that applications changes rapidly, new functionalities are being added, old are being rewritten and along with this process tables and other db structures changes. When this happen your SP can no longer work correctly. When do you know that they should be fixed? Only when you run them. When do you know that you need to fix EF query because table changes? During compilation. And performance lost? Generally nowadays we have fast and quite cheap machines so we do not care that much. I examined once execution time of EF query and its sql equivalent - plain sql gained me decrease in execution time like 5% - this is nothing for me. And as sql queries are much more complex there is high probability of writing your query in wrong way so that it will be unnecessary slower. And finally, if you need in your app really great performance for some complex query - write it as SP and execute it easily with EF.
When it comes to security EF query generators always use sql parameters so they are as safe to sql injections as SP.
You can use scaffolding to create DB and views and replace the calls to inbuilt methods by your own methods.
I'm very new to SQL and relational databases (just started learning last week) and I'm in the process of upgrading my website and currently keep all my data in XML files. It works, but the new site would be better suited from what I hear a relational database can do, and it looks like SQLite is best for me. One of my concerns is concurrency, even though 99% of the data will be read-only (which I understand SQLite is pretty good at) 99% of the time. Other things, like page view counters for certain pages will constantly require small writes. I'm still learning database design and want to do it right. Would it make sense to make separate databases for things that get written to a lot, that way making the main database far less susceptible to concurrency issues? Is it possible to do a "foreign key" type reference (I still haven't used foreign keys yet, but think I understand them) across databases? As each view count would point to some primary key in the main database. Thanks for any help!
SQLite is good to use in embedded systems (like mobile phones and tablets) and small desktop applications (Chrome, Firefox, Thunderbird, etc). However, when you need to have many concurrent readers and writers (typical for websites), you should not use it.
Even if you split your data in many databases, it has a lot of operational overhead. For example, it will be difficult to join data from different databases - you must use ATTACH, and by default you can only ATTACH up to 10 databases. And concurrency issues will still not go away 100%.
Instead, use real database like PostgreSQL or MySQL. Not only it will be faster, these databases provide real concurrent access to your data over the network, which SQLite cannot do.
My personal preference is PostgreSQL, but if your web hosting does not provide PostgreSQL, you can use MySQL, but then please use fully transactional engine like InnoDB.
I want to know, is there any reflection support in SQL Server 2008, like as c# support reflection. Basically I am curious about how SQL Server implements all our (where, orderby, exists) clauses. How it would implement all these in behind the scenes.
It's not that long ago when if you compared SQLServer to most object-oriented languages, that you would have been struck by the fact that SQLServer reveals a lot more about its inner workings than they do.
Its inherent to the concept of SQL and transactional databases, that a lot of the information about how they work is stored in the database itself. All tables are, for example, represented by rows in a table in a system database, as are all columns, stored procedures, and so on.
These days however, SQLServer does not go as far as C# in this regard, and you may be struck by the opposite conclusion.
An analogy could be drawn to the way that when you are browsing through reflected information on classes, you will hit "atoms" in the Democritian sense of something that can't be broken down any further. Either it'll be handled by the core IL instructions, or it'll be defined externally, and either way you can see any more "into" the implementation. SQLServer has more features that you can't peer into to see how they work than .NET
You might enjoy taking a look at PostgreSQL, which goes a bit further in how visible many of its functions are.
I want to use an ORM, and have been looking at EF 4. Is this platform scalable. I see a lot of stuff on the web, but everything looks very biased in one way or the other. Anyone know of benchmarks or non-subjective information.
On that point, does EF prevent SQL injection or XSS. I know that it used parametrized queries, but is that enough?
Any help is appreciated.
Okay so i see two questions here.
Is EF Scalable
Very difficult (and subjective) to answer, but IMO yes.
Here's a few reasons why:
Utilizes a common querying language (LINQ)
Allows for multiple providers (SqlServer, Oracle, etc)
Allows bi-directional mapping (code first, model first, database first)
Includes "classic ADO.NET" support (stored procedures, Entity-SQL)
The main real benefit in scalability is how the framework is built on LINQ-to-Entities. When you write queries, you are not writing against SQL Server or Oracle, you are writing against the Model. Depending on what Provider you have setup (in web.config), EF will translate these model queries into the appropriate T-SQL (or P-SQL).
Therefore (theoretically), you could write code against SQL Server, then change the web.config provider to Oracle, and your code should work. Obviously this isn't the case for Entity-SQL though (as you are writing T-SQL, not LINQ).
Does EF prevent SQL injection or XSS
No ORM tool can really "prevent" SQL Injection attacks - they can only provide the developer with the tools to prevent it.
As with classic ADO.NET where you use parameterized queries, Entity Framework has Entity-SQL, which allows to to execute pre-generated SQL, stored procedures, etc.
In this scenario, you need to use parameterized queries to prevent SQL injection. For most EF work, you will be writing queries with LINQ, which is a lot safer because it gets hydrated through a lot of stages before it becomes SQL.
XSS is exploited on the client-side via things like injected JavaScript, dodgy emails, etc. Has nothing to do with Entity Framework. Prevention of XSS is done on the client-side with things like HTML encoding.
No. ORMs are not a panacea for scalability. There is such a things called the impedance mismatch of objects and databases which has been around for many years. ORMS try to solve this by providing magic code generation/mapping solutions that give the appearance of just working with objects.
In a multi-tier environment with many client programs and a single/many server scenario, for every change that has to be committed to the database, checks need to be performed to make sure that your not over writing someone elses change on the data, or trying to update data that has been removed. This is not a new problem introduced by ORMs but one which appears many many times throughout the ages of updating databases in N-Tier environments. ORMS do not solve this problem. In some cases, if the ORM is the single entry to the Database, the ORM becomes a bottle neck. This means that to create a scalable architecture using an ORM becomes problematic as having DB checks performed on the ORM means that the update anomaly checks could be by passed if your using an N-Tier ORM solution where you have duplicate ORM tiers.
For the reasons above, this is why we use stored procedures. But if your using stored procedures, which naturally obfuscate the underlying data structures of the database then this increases the impedance mismatch of objects and database entities. One thing about using stored procedures and relying on table locking/row rocking, some of the update scenarios are solved, as we shift the bottle neck to the performance of the underlying database design.
So whats the answer. Don't use objects for databases. Object are great for analysis, bad for code design when interacting with RDBMS databases.
If your really thinking SQL and RDBMS data solutions are a problem, which in some scenarios they are, take a look at some of the NOSQL solutions out there. Still not a panacea for all problems, but in some cases they provide a better solution than a straight SQL solution.
Objects are not the answer to all problems. Step back from your code, take a look at what your trying to do, and think if an object is the right approach.
As for security, no ORMS do not aid security. Although they do help prevent some forms of injection attacks.
What I want to do is convert my whole application to nhibernate from ADO.NET and test it using different databases. i know nhibernate supports many different databases so can i switch between different databases without changing any of my application or nhibernate code?
As long as you do not write any specific queries targetted for a specific DMBS (which is possible using NHiberate (ISession.CreateSqlQuery), I would say that it is possible.
But, queries that have been written using hql or ICriteria API should work out of the box on other DBMS'es. (Provided that NHibernate supports those DBMS).
Although, it might be necessary to change some config settings (http://fgheysels.blogspot.com/2007/07/nhibernate-ms-access-problems-with.html for instance).
The short answer: yes. The long answer: It depends :-) I've done this numerous times, switching between SQLite (during early development and unit testing) and SQL Server (for later development, integration testing and production) with no code changes or recompilation - just Web.config changes.
If your application is fairly complex then you might run into some portability issues, but NHibernate is still a no-brainer if you want to support multiple RDBMS products for your application. Any such portability issues will usually be fairly straightforward to work around.