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 working on a collaborative-filtering recommender system. I built such a system before in a parallel-threaded environment, querying RDF with SPARQL. This worked well, because of the parallel nature of SPARQL and RDF graphs. However, I am now working in a standard desktop PC, and am wondering if using SPARQL is still the way to go in a largely serial environment. I've looked at dotNetRDF, as I'm using C#, and am wondering if it is any more efficient than simple SQL, especially now that dotNetRDF seems to be moving away from a SQL back-end.
So as far as performance on a few threads go, SQL or dotNetRDF? Tables or graphs?
The two things are not really comparable, dotNetRDF is a programming API that provides support for a variety of storage backends in addition to a pure in-memory solution which we mainly recommend for testing and development (Disclaimer I'm the lead developer)
The different backends have a wide variety of performance characteristics so if your problem is expressible in RDF then likely there is an appropriate backend for you.
SQL is a query language, really you should be comparing SQL to SPARQL and ultimately which you chose comes down to what your data model looks like. If it's regular then you likely want to use a RDBMS and SQL, if it's irregular and/or graph like then you likely want to use a triple store and SPARQL. The two have different pros and cons as your own answer implies.
This seems to answer it well enough. Triple Stores vs Relational Databases
Essentially, RDF is much more flexible, but expensive. Since I'm just doing collaborative filtering with data that fits pretty well into a table, I don't think I need the extra expense, as much as I like graphs.
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 3 years ago.
Improve this question
I am beginner to .net core. And I am working on an enterprise application where there are multiple classes interfaces for multiple project inside a one solution. i know Entity Framework won't be a good idea if we are facing huge number of wrappers. But indeed its giving me efficiency of coding. On the other side of it Entity SQL has its own benefits.
But still want to really understand the best practice and which one to implement when it comes to Enterprise application knowing it will have number of classes, Data filtration, Generic Types, Flexibility, performance vise when querying DB.
Looking forward to get some really helpful understanding from experts. Thanks in advance.
TL;DR;
The "best practices" depends on the use case. Its a set of tools, not a silver bullet.
Sometimes EF works for your case, sometimes not. Sometimes you want a monolith, sometimes you dont.
Try, experiment fail and succeed.
Best practices regarding to techniques are irrelevant; implementation change all the time. So;
define functional requirements
define none functional requirements
do a PoC with some relevant loads etc.
At enterprise level consider these additional properties:
security
operational functionality
cloud / none-cloud
This is the best I can do, given your question.
Explain the case and we could give some direction; but its not a template fitted for all cases.
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
LINQ just seems to generate horrendously optimised SQL (in general). I can write way more efficient T-SQL myself.
Do huge websites with my thousands of daily visitors use LINQ? Or should LINQ at some point be ditched? And if so, with what? and when?
Do huge websites with my thousands of daily visitors use LINQ?
Yes. Why not? Most SQL is trivial and you can always fall back to a stored procedure where it matters.
And that is the point. Let LINQ handlethe easy 80% and focus on the more complex.
And ther rest you handle by not talking to the database - caching is not that hard to plan for.
What I have done with my apps, when L2S or EF creates inefficient T-SQL is to create a view that does exactly what I want, in an efficient manner and I just have L2S or EF query the view.
In fact, this website (stackoverflow) uses linq2sql extensively, although I believe they are using a micro-orm (sqlfu?) for some of the heavier taks..
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 a beginner in c# and i'm looking for the best way to connect to and work with sql server in c#. i found there are three ways to work with databases:
ADO.NET
Linq
Entity Framework
but i become confused as to which one is more useful and applied.
please help me?
thanks
I'm looking for best way to connect to and work with sql server in c#
'best way' can be treated differently depending on your project requirements. There is no best way for all cases. Some times you need ease of development, some times you need best performance, some times you need compromise of both (then I pick Dapper). Also it depends on complexity of your application - whether you have rich domain model, or you simply display table data on UI.
1.ADO.NET
Fastest way, but requires lot of manual coding. You should manually setup database connections, open and close them, create commands, provide parameters to commands and execute commands. Mapping of query results also should be done manually.
2.Linq
It's not way to connect to database. Linq is language integrated queries, which have many implementations - Linq to Xml, Linq to DataSet, Linq to Object, Linq to SQL, Linq to Entities etc.
3.Entity Framework
Entity Framework uses Linq to Entities and it is built on ADO.NET (internally Linq queries are are translated to ADO.NET code). It is easy to use, because EF handles connections, generate and execute commands, and map query results to entities for you. But you should pay with performance for that.
There is only ONE way to connect to a database . ADO.NET, more specifig: the Connection object.
Now, LINQ, ENtity Framework - guess what, they do not talk to the database. They use ADO.NET to do that.
They are all about easier programming in the application - talking to the database is done by the same underlying classes. Everything goes through a Connection, a Command and a SqlReader if data is returned.
That said, definitely learn Entity Framework - an ORM is baseline and writing handcrafted SL should be left to those instances it makes sense. Very complex queries that can not be expressed in an ORM form. And learn proper SQL - databases can do a LOT more than most people are aware of.
There is no "best way", because there are many advantages and disadvantages to each one of them, so it depends.
For example, entity framework is heavy, but convenient way to connect to database. It generates objects from your tables and views automatically.
LINQ is less heavy, but some people find it less convenient.
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 3 years ago.
Improve this question
I want to use full text search in my project... Can anyone explain me, what is the difference between ElasticSearch and SQL Full Text Search
Or
why SQL Full Text Search is better (worse) than elastic?
documentations, presentations, schema...
Define "better"... sql full text search is fairly trivial to get working (indexing and query) - but it has penalties:
very little (virtually no) control over how things are indexed (what the index keys are; what the lexers/stemmers/etc are; etc)
runs on the sql server - which is usually your least scalable infrastructure
Elastic search requires more work; you need to setup and maintain a dedicated cluster of nodes, and then provide code that performs the actual index operations, which may also involve a scheduled job that works from a change-log (processing new / edited data), building the fragments to be indexed; equally, you need to then take more time building the query. But you get a lot of control over the index and query, and scalability (a cluster can be whatever size you need). If it helps any, Stack Overflow grew up on sql full text search, then moved into elastic search when the limitations (both features and performance) proved prohibitive.
The answer depends on what goal you're trying to achieve and what resources you have to reach it. SQL server fulltext search is lower admin but limited in functionalities. Elastic search is at the other end of the spectrum.
SQL server fulltext search:
can prove efficient if you're data is not considerable growing and or schema is not changing over time
requires less effort to maintain and less of a learning curve/need for new competence
Elasticsearch:
need for data ingestion if your master db is having frequent incremental updates (logstash and other alternatives)
scales better horizontally
ability to use advanced features to improve performance for very large data sets (eg. routing)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
So I am starting up an MVC application with entity framework and have invited a friend who is more database heavy into the project and he suggested ditching entity framework and using reflection as an ORM (object relational mapper). Does anyone have any good web posts or literature to provide that would compare the two techniques and list out pro's / con's to both?
An ORM is a big complex product with lots of services, such as:
materialization
lazy loading
persistence (including sequencing)
change tracking
identity management
query abstraction (DSLs, LINQ/expression trees, etc)
model abstraction (non-trivial mappings between the domain model and the data model)
database vendor abstraction
Reflection can provide a small part of that - in particular it can help with materialization and inspection (for persistence etc), but not all the ORM features. Now, in a lot of cases you don't need all those features - which is fine. But reflection is (comparatively speaking): slow. Which is why tools like ORMs use a large amount of meta-programming to make them fast; and trust me - you really don't want to write lots of meta-programming code unless you are experienced in that area.
But: this is a solved problem - even if you don't want to use a full ORM, the areas touched upon by "reflection" are addressed by the smaller, simpler "micro-ORM"s - things like "dapper", "peta-poco", "simple.data". Before you go reinventing the wheel: try one of the micro-ORMs. They are a lot smaller and simpler, and usually quite noticeably faster than the full ORMs - and as the trade-off they don't offer the full wealth of services that full ORMs offer.