|
Gerry Schmitz wrote: Only if you write NON-ANSI SQL
Huh?
Last time I checked there is no 'ANSI' specification for stored procedures. What exactly is your source for that?
Gerry Schmitz wrote: don't understand database performance and security
I have written large systems. Multiple database vendors. And I have never seen a 'standard' that allows you to generically code for performance. You can impact performance at the enterprise level both by architecture and requirements but tuning for performance at the database level depend on the database.
|
|
|
|
|
In 20 plus years of development, I've never had a boss say, change to a different database platform. I feel like this is an argument for the sake of arguing instead of adding actual software value. Using stored procs and embracing a vendor's specific optimizations makes a platform faster.
If we expand the idea, do you also eschew cloud computing because it creates vendor lock in?
Hogan
|
|
|
|
|
Trust me, it happens more often than you think. Oracle to SQL Server? Significant cost savings. Either of those to Postgres or similar FOSS dbms systems? Again tempting reduction in licence fees. The obstacle? The cost of overcoming that vendor lock in.
If you've never come up against this, you're lucky.
No, I don't eschew cloud computing for that reason. With modern containerisation that's nothing like the same problem.
"It's never happened to me" doesn't mean it never happens. I've never been shot in the head, but it obviously does happen. So far I've been lucky but I still try to avoid inviting it.
|
|
|
|
|
A twenty year career is quite short. Keep going.
|
|
|
|
|
Its a start. I can't make it go any faster and wouldn't if I could as I'm enjoying every day getting there.
Hogan
|
|
|
|
|
Excellent; no-one can ask for more.
However I await with interest to hear your feelings when you are tasked with a database migration on a tight schedule and find that... it's stored procedures all the way down 😉😂
|
|
|
|
|
A twenty year career is quite short. Keep going.
|
|
|
|
|
snorkie wrote: In 20 plus years of development, I've never had a boss say, change to a different database platform
I have.
Examples
1. The company's product supported three different databases. The company had three customers and ALL of them were on a database that the product did not support. So the customers were running the other database in their data centers just so they could use the product even though they did not have the real expertise for the database. (I started the conversion just before I left.)
2. Legacy company was running one server and they had outgrown it due to very expensive licensing. So they wanted to switch to another vender.
3. There was at least three companies involved in a contracted application. At some point it was miscommunicated what the actual targeted database vendor was. So it had to be converted mid-contract to the different vendor.
4. Legacy application had been converted to 3 different databases over time. The reason for each conversion was an attempt to increase performance. I wasn't involved in any of those conversions but I was involved in doing some clean up which only existed as an artifact of how the 2nd database system worked.
5. At one company, although it didn't happen when I was there, the new CTO in about the first week claimed that the company was going to convert all existing code from X to Y. And all existing databases from Vendor A to Vendor B.
|
|
|
|
|
haughtonomous wrote: they tie your work to a particular DBMS vendor, for a start
Unless you design and TEST your product for multiple databases from the beginning then it will be tied to that vendor regardless. Yes I have done such conversions multiple times.
And you can contract out the conversion of stored procs for a new database. That is a service provided by many places.
Conversely attempting to find and individually modify code in multiple places in legacy systems will be a substantial amount of work.
|
|
|
|
|
Of course the client code runs on the client.
The SQL still runs on the server and should be optimized there.
|
|
|
|
|
That's what I said: Stored procs. And why is that? Fewer round trips.
Actually, EF can also run on the server as part of REST, but most like to abuse it only from the client side.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
PIEBALDconsult wrote: Of course the client code runs on the client.
In C# the standard 'linq' API methodology to access the database relies on libraries (and versions) that are not necessarily correctly implemented to create the expected SQL.
I have seen expressions that I could see exactly how the SQL should look but instead resolved into things like the following. (No this was not a case of resolving a list incorrectly.)
1. The linq expression pulled the entire table then applied the where clauses in memory.
2. The linq expression, one expression, resolved to two different SQL calls which it then did the actual join in memory.
The only way to detect this happening is by profiling each linq statement.
|
|
|
|
|
You can use both EF and stored procedures together. Its not a either/or situation.
|
|
|
|
|
I have been using EF professionally for 10+ years now. Our websites and APIs run using EF.
I have no issues with EF and our team of 20+ devs are comfortable using it.
Microsoft pushes this technology because it works and it works well for its intended purposes. Its a tool, and like all tools, you either learn how to use it or you don't.
|
|
|
|
|
Admittedly, many of the ill feelings towards it go back to its initial release all the way back in 08 and release 2010 or so.
It wasn't great then & then we just left it alone. After that we began using the Repository pattern & it made things reasonable.
A few questions:
1. is there a good readable book that you would recommend that shows how to use EF for many database "structures" (master/detail, linking tables, etc)?
2. Do you find that it can be used well in cases where there is a master/detail type of relationships & you need to update data? Is it straight forward?
3. Have you found places where you can't get there from here type of behavior?
4. What are the most challenging data inserts & updates you've come across while using EF?
Thanks for your input.
|
|
|
|
|
EF is not SQL. It's a "table to entity" (or entity to table) mapper; and saves me a lot of work in that area.
If the only SQL one knows is "SELECT *", and doesn't ever use stored procs, then there will be issues.
I just make sure my "model" goes both ways: code first or data base first; and can use either one at any time to drive changes in the model in either direction.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
modified 28-Dec-22 23:29pm.
|
|
|
|
|
I bake "guaranteed future employment" cakes with inscrutable ingredients 
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
sql and stored procedures are a bore to maintain... code is better....debugging etc.....i used third party orms and way better, always avoided stored proc ....
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
raddevus wrote: library Hibernate, it was actually more code to write than the equivalent behavior written in SQL, subjectively at least; the SQL was also easier to understand.
Of course though "subjective" is subjective.
But other than that, in my experience, those that are really excited about packaged database layers are those that either have no or little experience using database(s) directly. So of course for them doing no database work would seem like an advantage.
They also seem to ignore the potential design problems of ignoring the database itself as part of the architecture because when they start with the data sets are all very small.
|
|
|
|
|
That's actually a perfect summary of the challenge/problem. 
I agree, because for example, EF works for those it works for and doesn't for those who it doesn't.
Most of the time EF works for those who don't know DB tech (sql, stored procs, etc) and doesn't "work" for those who would rather not have the layer between them and the DB.
6 one way, half a dozen the other. 
There are the poor unfortunate souls who begin using EF to solve all their problems & don't understand it or DB tech and then believe it is EF's fault.
There really are advantages & disadvantages to both courses of action.
|
|
|
|
|
Just noting also that I have never used a database layer that did not require, over time, a hack either around it or through it to achieve the necessary goal of using the database correctly.
Although the scope of such work arounds should be limited over time they start to add complexity to the application because they are not fully integrated. This means, for example, that someone uses the work around because they did not understand how the API could be used to achieve the same thing. Or alternatively they failed to realize that the hack would be a better solution so they do things like multiple queries in the code and then doing in code correlations with the result.
|
|
|
|
|
These experiences that you talk about are exactly my experiences.
So interesting. Thanks for sharing these stories. I always feel like it is just my limited knowledge of the API but sometimes you just put so much time into learning it at some point you got to just do the thing. Then later you discover, oh, that's not what the API creator intended, but it is what the API creator led us into. 
|
|
|
|
|
All morning, my notification tray has been telling me I have no internet access. My browsers, fools that they are, think differently and are unwisely displaying the pages they cannot access and playing the videos they can't connect to.
This is the machine I am using to type this post, which I can't be doing as in theory I can't get to the CP website.
Clearly, you are also not reading this.
|
|
|
|
|
You must have a quantic computer that is and isn’t connected to internet at the same time 
Mircea
|
|
|
|
|
Karin Krog, Bengt Hallberg: I ain't here[^]
On the more technical side: Could it possibly be that you have inadvertently defined an internet connection #2, and because it happened inadvertently, it is incomplete, and that is the one that the notification tray indication tries to report from? If the definition is incomplete, it makes sense that it doesn't work.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
