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 1 year ago.
Improve this question
A legacy database project was built as SQL DataSets (80 DataTables with about 1000 Functions). Now we are modernizing the project to better technology. What concerns of choice to migrate to Linq2SQL or EF.
PS.
We don't want to re-write the entire database queries. I found a tool that helps generate Linq query from SQL query. Is there something similar to convert to EF?
LINQ to SQL is obsolete technology.
EF Core is modern way but has a lot of limitations in LINQ. So probably you will create new 100 functions when EF fail to translate your query.
Also consider look at https://github.com/linq2db/linq2db (disclaimer: I'm one of the creators).
You can scaffold any database via T4 template. Functions also will be imported.
Difference between EF Core and linq2db, that linq2db has no ChangeTracker but it uses LINQ for CRUD operations. And actually there are almost no limitations in creating fast and correct SQL.
For translating SQL to LINQ I know only one tool http://www.sqltolinq.com/ I've tried that many years ago and don't know current status.
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 7 months ago.
Improve this question
I have a project that started simply enough with EF Core code first. I would create migrations and apply them with dotnet database update - I even have CI/CD apply the migrations to the prod DB once merged into the main branch.
Overtime however, the database complexity increased; views, stored procedures and functions were created to handle some cases that perform much better by remaining on SQL Server. The problem is the tables are now tracked in a SQL Server .NET Core project as well as in the the code first classes in the business layer of the app. With multiple developers, there is a path that a change made in one project is not reflected in the other. Policy and code reviews are the only gates we have.
What is the recommended approach here? I am currently of the opinion that since we have complex SQL objects such as views, stored procedures, function, etc... that we should treat the SQL Server Project as the source of truth and scaffold the EF classes but that fundamentally, the source of truth should be the SQL Server project and its changes should be applied to the database using Flyway or LiquidBase.
Yes. Code First design workflow is inappropriate when the database has significant SQL artifacts other than tables, or when the database design is performed by team members without .NET and EF expertise.
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
Our DBA recently introduce the whole idea of DB Project for maintaining sql (DDL and DML) check in part however I feel like it's of no benefit at all. Is anyone knows any benefit of using DB project ? I would like to know real benefit.
Is anyone knows any benefit of using DB project ?
1) It tracks the change history of your database schema, and stores your schema in a version control system.
2) It integrates with your DevOps workflow, and enables you to track what version of your schema is deployed in what environment.
3) Manages the creation of DDL change scripts for upgrading a target environment to a specific version of the schema.
4) Prevents Schema Drift in environments by detecting and fixing changes made directly in environments.
An easy way to get started with database projects is to continue with your connected database development workflow, and use the Schema Compare tool to update your Database Project and check it in to source control.
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 4 years ago.
Improve this question
I have a question: what is the best practice for migrating SQL Server stored procedures to Oracle?
Thanks.
Best is such a fun word.
But.
Oracle SQL Developer has built in translators, including one for SQL Server.
If you capture your data model using the Migration Projects feature, it will take your T-SQL procedures and convert/translate them to their PL/SQL equivalents.
Each translation will need to be verified/approved/tested, of course.
We see somewhere between 60-90% translation success rates, that is, translated procedures being 'good, out-of-the-box.' Results will vary based on the nature of your code.
I talk about migrations, with Sybase ASE as an example, in this whitepaper. The SQL Server scenario would be pretty much the same.
We also have an ad-hoc translator, but it won't take into account your data model.
I can attest from being involved in a large production legacy project, where substantial number of "automated" options had been evaluated - none of them worked, and almost nothing they did could even be used in the 'at least that' manner.
We wasted a lot of time trying to achieve automation, and then ended up converting everything by hand, which took much less when we involved a small team of coders, once they familiarized themselves with both syntax and optimisers.
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 imagining a setup of a three-layer web app, MVC 3.0 with ADO.NET using Linq to Entity. Build is VS 2010, Server OS MS Server 2008, database MS Sql Server 2008. Language is either C# or VB.
What is the preferred mechanism to add a column to a table in the database?
What is the best mechanism to refactor a column type in a table?
The question is about maintaining sync between the db and the entity model. As compared to the "typical" RDBMS-SQLClient scheme, the Linq variant seems to carry a lot of overhead for these DDL operations.
Possibly, I'm just missing something....
Steve
Depending the architecture you will follow you can get the desired behavior.
Using Database first model you must maintain your model classes through the designer adding tables from the database and thats where you add/refactor a column, update the dbml and then generate a change script for your database.
If you create a Model first design then you create all you model classes in the designer and then generate a script to create the database.
In my opinion, best practice for the moment that you have full control and is more "developer" oriented approach is code first. Create all your classes programmatically as you would do like every object, create a library to map your classes to the desired database with fluent API (you can create several libraries for diferent data stores) and you can also you migrations for your changes. So you can create all your classes with a "database ignorant" way and maintain through migrations, or just create change scripts through a compare tool like Red Gate's SQL Compare.
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 2 years ago.
Improve this question
I have been given an assignment to get the feasibility for making a dll which takes some inputs such as database name (Mysql, access, sql, oracle etc.) and some more inputs to generate a query, and based on that the dll should return a recordset to the application.
Is it a good idea? If yes, then what inputs should I consider?
It's completely feasible, the issues arise when you encounter different SQL grammars - take a look at how Hibernate handles this with the use of Dialects.
The popular databases - Oracle, Sybase, MS SQL Server, MySQL - have slight differences in the SQL grammar they allow. Essentually the vendors have implemented and extended ANSI SQL in different ways.
The simplest case I can think of is when the way you assign pseudonyms to column names, some databases require this:
SELECT x AS y FROM some_table
while others require:
SELECT x y FROM some_table
There's many more such examples, but the bottom line is that when writing a query abstraction layer that works across all databases you need to abstract the concept of SQL generation so that it can be tailored to each database you are going to support (as I said, Hibernate does this by allowing you to specify a dialect specific to the database you are using).