|
I've discovered that if you pay attention to the execution plans you can usually improve your query performance by forcing the T-SQL query optimizer to select different pathways.
|
|
|
|
|
it is the internals about how T-SQL is logically executed before SQL optimization.
diligent hands rule....
|
|
|
|
|
PIEBALDconsult wrote: I don't know what, "logical query processing", means.
In other words, his question was an illogical query that couldn't be processed? 
|
|
|
|
|
Southmountain wrote: Teradata SQL
I didn't even know Teradata SQL[^] was a real thing. I figured you were just guessing at the "T", like it could be Pterodactyl[^] SQL. 
|
|
|
|
|
thanks for the first link!![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
diligent hands rule....
|
|
|
|
|
Southmountain wrote: Is this logical query processing the same for Teradata SQL?
Unlikely.
Even if the vendor was the same it would be unlikely.
The factors is systems like these.
1. Age. How long the product has existed.
2. Specifics of the application
3. Presumptions from the developers about how it will be used
4. Acquired knowledge about how it is used.
All of those lead to solutions that attempt to increase performance. So the implementations are different.
Could it be the same? I seriously doubt that. Even if someone stole the code it would still end up different over time.
Could there be similarities? Yes.
So presumably you are asking if the book you are reading might help you with understanding the other. So the last point makes it possible.
|
|
|
|
|
How many of you are still using Linq-To-SQL versus Entity Framework?
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
Never neither.
I just use straight ADO.net for access to whatever database system I need to connect to.
If I understand correctly, those connect only to SQL Server.
Using ADO.net allows an application to connect to multiple database systems, even allowing the user to specify which at run time if the application is written that way.
|
|
|
|
|
What are you using?
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
PIEBALDconsult wrote: If I understand correctly, those connect only to SQL Server.
You understand incorrectly then.
EF uses ADO.NET under the hood and also supports SQLite, MySQL, PostgreSQL, Azure Cosmos DB, Firebird, Oracle...
PIEBALDconsult wrote: Using ADO.net allows an application to connect to multiple database systems, even allowing the user to specify which at run time if the application is written that way.
How often is that a requirement? 
|
|
|
|
|
More often for me than for others probably.
|
|
|
|
|
Well, still possible using EF.
|
|
|
|
|
|
Imagine you'd learn something new.
|
|
|
|
|
I use all three:
Dapper
Linq2SQL
EF
Depends on the project, but the combination is only Dapper+Linq2SQL or Dapper+EF.
Much of what I do is highly abstracted, SQL generated on the fly, so Dapper is a godsend. And unless I'm doing business logic on something, mirroring the models in C# is just stupid, in my opinionated opinion. 
|
|
|
|
|
Marc Clifton wrote: SQL generated on the fly
I don't do that very often, but I may accept SQL from a script or the command line.
|
|
|
|
|
Marc Clifton wrote: Dapper
Linq2SQL
EF
We use these 3 as well in our shop.
|
|
|
|
|
Quote: ... in my opinionated opinion.
Hey, if you're going to have an opinion, that's the only kind to have!
I have lived some thirty years on this planet, and I have yet to hear the first syllable of valuable or even earnest advice from my seniors.
-- Henry David Thoreau
Ok Boomer.
-- Anonymous Millenial
|
|
|
|
|
How come opine is similar to a tree and opinion is similar to an onion?
|
|
|
|
|
Slacker007 wrote: opinion is similar to an onion
Or similar to just winging it.
|
|
|
|
|
Have not used this myself, but it looks interesting: Linq To DB[^]
It supports popular databases like MS Access, MS SQL Server, PostgreSQL, MariaDB, SQLite, Firebird, DB2, Informix and Oracle.
|
|
|
|
|
Interesting
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
I don't use either these days, but I haven't touched anything .NET related in like 7 years. Seems like forever.
Nothing against them. These days I'm in the Node ecosystem.
Jeremy Falcon
|
|
|
|
|
Neither: I use SQLConnector, SQLCommand, and Reader / Adapter and DataTable as necessary.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
IDbConnection, IDbCommand, IDataReader, IDbDataParameter, DataTable, DataView. I can use any database system which provides an ADO.net provider/connector (and preferably SQL-92).
By the same token, I can implement a class which is not a database but which provides an IDataReader.
No adapters, I stopped using those years ago; too much trouble. If I recall correctly, the biggest issue I had with an adapter was that it implements concurrency protection (I may have that wrong) which can't be configured off and every once in a while an update would fail because of it -- when in fact having two updates for one record in the same batch was perfectly fine for the particular situation. So I stopped using them and never looked back.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
