Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am working on an application that needs to save and retrieve data fastly from database.I am using MVC5 razor view with C#.
Scenario may be like there is a post that can be like/unlike by any user and data will be store in database, also user can share that post. For example, facebook. on facebook we like/unlike posts and it is works very fast.
Can any one tell me which database tool**(Sql Server, MySql, Oracle etc)** should I use and which data approach**(Entity framework, Store Procedures, ORM, NoSql etc)** should I use in my scenario ?
Thanks in advance....
Selection of the database completely depends on you.
and it is also dependent on the cost as mysql is free of cost.
You have to identify your requirements and then need to select the database tool.
if you are only considering the speed then you need to read about Entity framework, Store Procedures, ORM, NoSql.
These are the different approaches used for differnt purpose
As Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a “virtual object database” that can be used from within the programming language.
So it completely dendends on your requirement.
But first i will suggest you to read more about these concepts.
thses two links will definitely help you to understand more.
https://kevinlawry.wordpress.com/2012/08/07/why-i-avoid-stored-procedures-and-you-should-too/
http://www.davidwaynebaxter.com/tech/dev/orm-or-sprocs/
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have a web page where I need to get fields from many tables in SQL that can all join. Is it better in terms of performance to do a few queries to the database or one big SQL statement. I'm using MVC with Web API calls.
Thanks.
In the past I've created DB Views to define the data I'm looking for. Depending on the data access framework you are using this can also be helpful in returning the data and translating it to objects.
As far as performance goes, I'm most familiar with SQL Server, and in the Management Studio there is an option to "Include Actual Execution Plan". This will show you a full breakdown of your JOIN statements, what indexes are being used if any, and will suggest indexes to speed performance. I recommend this tool to all developers on my teams when they are stuck with a slow performing page.
One other thing to note, the database configuration also makes a difference. If you are running a local database you will have fewer concerns than if you were running a cloud based database (Azure SQL, etc) as those have management overhead beyond your control when it comes to availability and physical location of your instance at any given time.
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 8 years ago.
Improve this question
I'm working on a project in which I have a PostgreSQL database containing various tables and what not. I have a c# application that needs to be able to enter new data/change existing data/ or retrieve data from the database.
My question is, is there some tool/framework that I should be using to make this interaction easier. Currently, we have written a bunch of database helper functions to make various common operations simple in C#, we've written classes that define what a Column and Table are. We have defined data model classes for all the tables in the database as well as defined table classes corresponding to each data model class.
Basically, we written a lot of code just to be able to interface with the database and I feel like there has to be a simpler way. But maybe not! That's why I'm asking.
I saw some people using the Entity Framework but I'm not familiar with it and don't know if it does what I'm looking for. Also, it seemed like it was geared towards MySql and the free PostgreSql tool for it were a bit hacky.
The short answer is: you are probably already doing it the best way with current technologies.
I have tried several ORM solutions and all of them failed to live up to expectations on one level or another. Entity Framework is starting to get mature, but as you already found, the PostgreSQL adapters are essentially hacks since EF is baked for Microsoft SQL at a low level. One of the better ones I have used is Telerik's ORM, but it costs $$$$ and is far from perfect (http://www.telerik.com/data-access).
One to look at is this: https://www.nuget.org/packages/Shaolinq.Postgres.DotConnect/ Note though that is is an early version, I have not used it myself and generally use at your own risk:)
There are some code first and Node.js specific tools out there that are starting to get interesting, but in the end, having some decent reusable data access library and object classes is generally still the best solution for general use.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm trying to query an existing SQL Server database with LINQ on a .NET project. I've been successful to do so by using LINQ to SQL .dbml files, but then I read somewhere I can't remember that this approach is deprecated, then I started investigating the other Data File Types ADO.NET Entity Model (.edmx), DataSet (.xsd), EF DbContext Generator...
I'm a bit consufed about when it is appropriate to use the different the Data file types (the several types of files available in VS), and which one is the most appropriate to solve my problem. Can anyone shed some light on this matter?
Thank you
In a recent post on extending NerdDinner, Scott Hanselman talked about this very thing. To quote at the end:
Conclusion
There's lots of choices for Database Access on .NET. You'll run into
DataReaders in older or highly tuned code, but there's no reason it
can't be hidden in a Repository and still be pleasant to use. LINQ to
SQL is nice, lightweight and fast and has dozens of bug fixes in .NET
4, but Entity Framework is the way they are heading going forward.
Plus, Entity Framework 4 is way better than EF 3.5, so I'm using it
for any "larger than small" projects I'm doing and I'm not having much
trouble.
http://www.hanselman.com/blog/ExtendingNerdDinnerExploringDifferentDatabaseOptions.aspx
Datesets was an approach used before the arrival of Linq. Linq-to-Sql and Entity Framework are both far superior to datasets, so cross that one out.
Linq-to-SQL (.dbml) is not really deprecated, but it is not being developed further. So you can use it if it satisfied your need, but the framework won't get any new features in the future. It is simpler and more lightweight than EM, so if you are familiar with it and it fits your needs for the project in question, it remains a fine choice.
EM (.edmx) have more features, and is being actively developed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am writing a small c# database application that will store sports statistics. There will be about 7 tables in the local sdf file that will store the data. One table for storing the player details, another table to store the game info and another table that will store the the actual stats from the game using the playerid and gameid as foreign keys. I personally see this as a small database as it will only grow by about 30 entries per week. The end result of this is to be about to pull reports out of the collected stats.
I am a little confused as to which way to access the data in the database. Datasets look ok, but when i want queries to access multiple tables or use the WHERE function in the query, things get a little troublesome. I was thinking of just directly accessing the database with out the need for datasets.
Opinions on the best options are appreciated.
Thanks
Datasets area relatively old technology which is steadily being replaced by Entity Framework. For any new development looking for a standard Data Access technology, Entity Framework should be your primary solution. The Model-Based option feels a lot like DataSets in the designer (you can design your model by dragging tables and relationships to the surface), but Entity Framework can also work directly against your code (EF-CodeFirst) which many people find better, since you have total control over what your code will look like (plus it won't get overwritten each time you save the datamodel).
Unless you are open to 3rd party libraries, in which case there are a couple of great open source alternatives that include NHibernate and a few others.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
When I read pro and con lists of using Entity Framework (or any modern ORM really), I'm surprised that the following point doesn't arise (self quote):
Using strongly-typed domain entities allows for type checking at
compile-time which essentially performs a verification of all your
database operations. This is something that is not possible with
ADO.NET (whether using inline SQL or stored procedures).
For me, this is one of the biggest advantages of using an ORM. An issue that I come across regularly when dealing with ADO.NET based applications are the run-time errors from SQL. Static checking completely eliminates this.
Could anyone elaborate as to why this isn't hugely relevant to many developers?
Oh it's great.
It's also not free. EF is essentially built on top of ADO.net, it just uses reflection to convert back-and-forth between strongly typed classes and the actual column names. This is fine if your recordset is fairly small, but it's very noticeable when you start dealing with larger sets of data.
Generally this extra lag time isn't important because if, say, the DB takes two seconds to pull the data up to begin with, what difference does an extra millisecond (or even a second) make. But there are situations where speed is critically important, and in those situations you pretty much have to write your own constructs using raw ADO.
The same question was asked here. It includes some good answers.
Programmers.stackexchange.com was a more appropriate place to ask the question.