September 27, 2017 at 9:17 am
Jeff Moden - Wednesday, September 27, 2017 9:09 AMDrop your egos or drop your pants for a royal screwing. The choice is yours.
This is a prime candidate for my new signature.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
September 27, 2017 at 9:18 am
TheSQLGuru - Wednesday, September 27, 2017 9:09 AMsgmunson - Wednesday, September 27, 2017 9:01 AMTheSQLGuru - Wednesday, September 27, 2017 8:42 AMHere's my Guruism related to ORMs (and numerous other things too):Anything that allows developers to slap code together more quickly is inversely proportional to the performance and concurrency you will get from that code.
And yet another + 1 googolplex to the googolplex power !!!
I think I should trademark my Guruisms!! 😎
Too late. I've already used it. 😉
September 27, 2017 at 9:21 am
ORMs like EF can be very useful when you know what you're doing and when you need to revert back to good ol' ADO. I have strong DB design skills and do all of that in SSMS. But for the application side of things, I use MS tools to reverse-engineer the database into a code-first model. I do not use the generated model to update the DB schema; I go back into SSMS, make my changes, and reverse engineer it again so any changes are available on the application side. With the generated classes being partial, I can create MetaData classes that I add all of my data annotations to (field names for display, validation, etc.) and they do not get overwritten when I generate from the model again.
With classes that refer to my DB tables and fields I almost never have to deal with "magic strings" in my code; everything is strongly-typed.
Don't get me wrong - There are still times when I use ADO, such as for firing off SP's, batch deletes or updates (which EF is supposed to have soon), etc.
Another thing the developer needs to know is that if you don't need every field of a table don't just do "await _context.TableName.ToListAsync();" Project it into a dynamic type so EF will generate a query that only includes the fields that are needed. It's important to remember when to use .Include() as well, so EF performs joins to get the desired data set in one request, instead of making another DB call for each related entity.
September 28, 2017 at 1:03 am
sgmunson - Tuesday, September 26, 2017 10:35 AMTheSQLGuru - Monday, September 25, 2017 4:01 PMI advise clients to NEVER EVER EVER do code first. I also advise them that IF they MUST use an ORM, they MUST READ THE FINE MANUAL OR BE CRUSHED BY BAD STUFF.+ 1 googolplex to the googolplex power.
I couldn't agree more. The idea of .Net C# folks designing databases in ANY tool, no matter how handy, should scare the CRAP out of ANY given DBA. This is HOW most of the problems I've ever had to fix came into existence. No thought to database architecture, and no thought to the overall design. Bad code = Bad performance, even if not right away, all it usually takes is a little data volume growth, and things start to "fall down, go boom"
Hey! Some of us design databases AND code in C# (and COBOL and VB6). 😀
September 28, 2017 at 7:04 am
Chris Wooding - Thursday, September 28, 2017 1:03 AMsgmunson - Tuesday, September 26, 2017 10:35 AMTheSQLGuru - Monday, September 25, 2017 4:01 PMI advise clients to NEVER EVER EVER do code first. I also advise them that IF they MUST use an ORM, they MUST READ THE FINE MANUAL OR BE CRUSHED BY BAD STUFF.+ 1 googolplex to the googolplex power.
I couldn't agree more. The idea of .Net C# folks designing databases in ANY tool, no matter how handy, should scare the CRAP out of ANY given DBA. This is HOW most of the problems I've ever had to fix came into existence. No thought to database architecture, and no thought to the overall design. Bad code = Bad performance, even if not right away, all it usually takes is a little data volume growth, and things start to "fall down, go boom"
Hey! Some of us design databases AND code in C# (and COBOL and VB6). 😀
And some of us even go further back with Fortran, BASIC, C+, and RPG. Anyone remember Lotus 1-2-3 for DOS and it's "3D" spreadsheets? At the time, MS asked me to do an EVAL on Excel 2.0. As I had Lotus 1-2-3 for DOS working quite well with the "3D" feature, Excel 2.0 was a massive shift in a whole new direction, and while claiming to be able to import a Lotus 1-2-3 spreadsheet, my 3D formatted golf league tracking spreadsheet was too much for it to handle, and my eval of Excel 2.0 was overall negative. It's not that it couldn't handle basic spreadsheet stuff, but it was missing any truly useful third dimension. My golf league 123 spreadsheet simply would not load, due to an out of memory condition. Not sure why, but it was abundantly clear that translating that third dimension into tabs was hopelessly screwed up. So even MS had crap for C programmers, and it was probably because while they may have understood the file format, they may not have understood the physical model that the data represents and thus had no idea how to translate it. I wouldn't trust anyone with a database that thinks that using the C language (any version) for anything is actually a ,good idea, because there's no logic in the world that can justify the use of a language for which the entire functional equivalent exists in VB, and is much better at being nearly "self documenting".
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
September 28, 2017 at 2:17 pm
sgmunson - Thursday, September 28, 2017 7:04 AMChris Wooding - Thursday, September 28, 2017 1:03 AMsgmunson - Tuesday, September 26, 2017 10:35 AMTheSQLGuru - Monday, September 25, 2017 4:01 PMI advise clients to NEVER EVER EVER do code first. I also advise them that IF they MUST use an ORM, they MUST READ THE FINE MANUAL OR BE CRUSHED BY BAD STUFF.+ 1 googolplex to the googolplex power.
I couldn't agree more. The idea of .Net C# folks designing databases in ANY tool, no matter how handy, should scare the CRAP out of ANY given DBA. This is HOW most of the problems I've ever had to fix came into existence. No thought to database architecture, and no thought to the overall design. Bad code = Bad performance, even if not right away, all it usually takes is a little data volume growth, and things start to "fall down, go boom"
Hey! Some of us design databases AND code in C# (and COBOL and VB6). 😀
And some of us even go further back with Fortran, BASIC, C+, and RPG. Anyone remember Lotus 1-2-3 for DOS and it's "3D" spreadsheets? At the time, MS asked me to do an EVAL on Excel 2.0. As I had Lotus 1-2-3 for DOS working quite well with the "3D" feature, Excel 2.0 was a massive shift in a whole new direction, and while claiming to be able to import a Lotus 1-2-3 spreadsheet, my 3D formatted golf league tracking spreadsheet was too much for it to handle, and my eval of Excel 2.0 was overall negative. It's not that it couldn't handle basic spreadsheet stuff, but it was missing any truly useful third dimension. My golf league 123 spreadsheet simply would not load, due to an out of memory condition. Not sure why, but it was abundantly clear that translating that third dimension into tabs was hopelessly screwed up. So even MS had crap for C programmers, and it was probably because while they may have understood the file format, they may not have understood the physical model that the data represents and thus had no idea how to translate it. I wouldn't trust anyone with a database that thinks that using the C language (any version) for anything is actually a ,good idea, because there's no logic in the world that can justify the use of a language for which the entire functional equivalent exists in VB, and is much better at being nearly "self documenting".
You young whipper-snappers and your Lotus 1-2-3 for DOS!! My first experience with computing was a "mini-computer" with punch cards at a college - although this was before I was even in high school! 😎
I did work with Lotus 1-2-3 though, had a father-in-law later that was an absolute master with it.
I have fond memories of hacking code with my first computer too - TRS-80 Model 3, with 4K of RAM and a cassette tape for storage!! My family lived pay-check-to-paycheck at the time and I still don't know how my parents saved the ONE THOUSAND US DOLLARS it took to buy that thing for me. Incredible sacrifice ... but it set me up for amazing long-term success, especially after my initial career choice ended with a medical discharge from the US Navy after just a year as an Ensign.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
September 28, 2017 at 3:59 pm
Phil Parkin - Wednesday, September 27, 2017 9:17 AMJeff Moden - Wednesday, September 27, 2017 9:09 AMDrop your egos or drop your pants for a royal screwing. The choice is yours.This is a prime candidate for my new signature.
😉
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2017 at 1:51 am
Jeff Moden - Thursday, September 28, 2017 3:59 PMPhil Parkin - Wednesday, September 27, 2017 9:17 AMJeff Moden - Wednesday, September 27, 2017 9:09 AMDrop your egos or drop your pants for a royal screwing. The choice is yours.This is a prime candidate for my new signature.
😉
I am the Developer and the DBA, will I have to drop both egos and do I really have to screw myself :blink:
Far away is close at hand in the images of elsewhere.
Anon.
September 29, 2017 at 6:28 am
TheSQLGuru - Thursday, September 28, 2017 2:17 PMsgmunson - Thursday, September 28, 2017 7:04 AMChris Wooding - Thursday, September 28, 2017 1:03 AMsgmunson - Tuesday, September 26, 2017 10:35 AMTheSQLGuru - Monday, September 25, 2017 4:01 PMI advise clients to NEVER EVER EVER do code first. I also advise them that IF they MUST use an ORM, they MUST READ THE FINE MANUAL OR BE CRUSHED BY BAD STUFF.+ 1 googolplex to the googolplex power.
I couldn't agree more. The idea of .Net C# folks designing databases in ANY tool, no matter how handy, should scare the CRAP out of ANY given DBA. This is HOW most of the problems I've ever had to fix came into existence. No thought to database architecture, and no thought to the overall design. Bad code = Bad performance, even if not right away, all it usually takes is a little data volume growth, and things start to "fall down, go boom"
Hey! Some of us design databases AND code in C# (and COBOL and VB6). 😀
And some of us even go further back with Fortran, BASIC, C+, and RPG. Anyone remember Lotus 1-2-3 for DOS and it's "3D" spreadsheets? At the time, MS asked me to do an EVAL on Excel 2.0. As I had Lotus 1-2-3 for DOS working quite well with the "3D" feature, Excel 2.0 was a massive shift in a whole new direction, and while claiming to be able to import a Lotus 1-2-3 spreadsheet, my 3D formatted golf league tracking spreadsheet was too much for it to handle, and my eval of Excel 2.0 was overall negative. It's not that it couldn't handle basic spreadsheet stuff, but it was missing any truly useful third dimension. My golf league 123 spreadsheet simply would not load, due to an out of memory condition. Not sure why, but it was abundantly clear that translating that third dimension into tabs was hopelessly screwed up. So even MS had crap for C programmers, and it was probably because while they may have understood the file format, they may not have understood the physical model that the data represents and thus had no idea how to translate it. I wouldn't trust anyone with a database that thinks that using the C language (any version) for anything is actually a ,good idea, because there's no logic in the world that can justify the use of a language for which the entire functional equivalent exists in VB, and is much better at being nearly "self documenting".
You young whipper-snappers and your Lotus 1-2-3 for DOS!! My first experience with computing was a "mini-computer" with punch cards at a college - although this was before I was even in high school! 😎
I did work with Lotus 1-2-3 though, had a father-in-law later that was an absolute master with it.
I have fond memories of hacking code with my first computer too - TRS-80 Model 3, with 4K of RAM and a cassette tape for storage!! My family lived pay-check-to-paycheck at the time and I still don't know how my parents saved the ONE THOUSAND US DOLLARS it took to buy that thing for me. Incredible sacrifice ... but it set me up for amazing long-term success, especially after my initial career choice ended with a medical discharge from the US Navy after just a year as an Ensign.
Just how young do you think I am? My first computer experience was in high school, with a 110-baud teletype access to the local community college's DEC PDP-8. I still own three of the DEC tapes that system was able to write on. My first personal machine was also a TRS-80 Model III, with 48K user RAM, 16KB ROM Basic. I eventually put two 5.25 inch floppy disk drives in it and added a wide-carriage printer, and wrote a program to hold bowling league data, so that the job of league secretary was reduced to about 15 minutes per week. I knew that machine inside out, upside down, and backwards, and even learned machine language for that Intel Z-80 cpu that ran at a whopping 2.25 MHz, or some 1,000 times slower than today's clock speeds, and of course, there was no 2nd or 3rd or 4th core. The entire address space was just 64KB. The screen was memory mapped at location 3C00 hex. I still remember using POKE to give myself a machine language speed demon of a routine to clear the screen, because CLS took way too long. When my routine ran, the screen was instantly clear. I used the LDIR instruction, which was Load, Increment, and Repeat. My machine cost me the princely sum at the time of $500, and was the best investment I ever made. I too, at the time, lived paycheck to paycheck, and on an E4 pay grade as opposed to anything in the officer category.
Just an fyi, but I'm pretty sure that the Model III came stock with 16KB of user RAM, and 16KB ROM Basic, and it was the Model I that came with just 4KB initially. The Model III I bought had the stock 16KB and I added 32KB myself by opening the case and installing it. The floppy drive upgrade I had Radio Shack do. I then later had them transfer the guts into Model 4, I'd acquired on the cheap, and then had to also upgrade that machine's stock RAM to the full 48KB because the two motherboards were sufficiently different that there was no way to transfer the RAM.
Anyway, I'm thinking we might want to have an actual conversation, as we seem to have a lot in common here. Send me a private message and I'll provide my number there.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
September 29, 2017 at 6:36 am
David Burrows - Friday, September 29, 2017 1:51 AMJeff Moden - Thursday, September 28, 2017 3:59 PMPhil Parkin - Wednesday, September 27, 2017 9:17 AMJeff Moden - Wednesday, September 27, 2017 9:09 AMDrop your egos or drop your pants for a royal screwing. The choice is yours.This is a prime candidate for my new signature.
😉
I am the Developer and the DBA, will I have to drop both egos and do I really have to screw myself :blink:
It means that you'll need to use both hands. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2017 at 6:46 am
Jeff Moden - Friday, September 29, 2017 6:36 AMDavid Burrows - Friday, September 29, 2017 1:51 AMJeff Moden - Thursday, September 28, 2017 3:59 PMPhil Parkin - Wednesday, September 27, 2017 9:17 AMJeff Moden - Wednesday, September 27, 2017 9:09 AMDrop your egos or drop your pants for a royal screwing. The choice is yours.This is a prime candidate for my new signature.
😉
I am the Developer and the DBA, will I have to drop both egos and do I really have to screw myself :blink:
It means that you'll need to use both hands. 😉
Funniest thing I've heard in quite a while... not sure I'm going to be able to stop laughing anytime in the next 72 hours... :):):) 😉
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
September 29, 2017 at 7:53 am
Chris Wooding - Thursday, September 28, 2017 1:03 AMsgmunson - Tuesday, September 26, 2017 10:35 AMTheSQLGuru - Monday, September 25, 2017 4:01 PMI advise clients to NEVER EVER EVER do code first. I also advise them that IF they MUST use an ORM, they MUST READ THE FINE MANUAL OR BE CRUSHED BY BAD STUFF.+ 1 googolplex to the googolplex power.
I couldn't agree more. The idea of .Net C# folks designing databases in ANY tool, no matter how handy, should scare the CRAP out of ANY given DBA. This is HOW most of the problems I've ever had to fix came into existence. No thought to database architecture, and no thought to the overall design. Bad code = Bad performance, even if not right away, all it usually takes is a little data volume growth, and things start to "fall down, go boom"
Hey! Some of us design databases AND code in C# (and COBOL and VB6). 😀
Yes, and that DOES scare the crap out of us DBAs!
As does the idea, in an earlier post, that dbs can be designed in SSMS. Note to developers, for the record: SSMS is not a data modeling tool. No, really, it's not.
Also, for the record, it doesn't have to take a long time to do a logical data model, particularly if everyone is properly prepared for the process. It's much more difficult, and time consuming, to complete the underlying "data dictionary", i.e., brief definitions of the entities, relationships, and, most importantly, attributes, including their domains.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
September 29, 2017 at 8:01 am
chuck.forbes - Tuesday, September 26, 2017 10:54 AMBased on my personal history, I am far more comfortable with designing the database first. But, I also want to keep an open mind if conditions have improved within the Entity Framework. What I have trouble reconciling with our C# developers is the concept of consistency and maintainability in the database, and that being lost with Code First. I've only been with this shop for 2 years, so I have a keen memory for coming in and being lost in their db designs, with missing referential integrity, mis-matched datatypes between "keys", missing indexes, and so on. These systems were all built pre-CodeFirst concepts, and so I am leery that the same patterns could re-surface with Code First. And that's all without even getting into performance issues from a bad design.Just re-reading my comments above I can already hear my soapbox scraping against the floor as I pull it out from under my bed to stand on. I really want to take a step back, though, and have a conversation with my developers about how well they can design from within Entity Framework, and then at least work backwards from as a mental exercise. Before I started, I was just looking to see if their toolset was better than it used to be.
--=cf
The theme of entity framework being used to create databases objects has bitten me more than once. The worst occasion was where I was troubleshotting a performance issue on a database that had no indexes, no relationships and no constraints. Why? Because the responsibility for these components was handed over to entity framework and the application. It was utter chaos.
My mantra is to let the RDBMS (Relational Database Management System - the clue is in the name! :)) deal with the ACID concepts and let the application represent the resulting data.
So in answer to the post: Once the project has been clearly defined and understood construct the database and build the application around it.
September 29, 2017 at 9:33 am
kevaburg - Friday, September 29, 2017 8:01 AMThe theme of entity framework being used to create databases objects has bitten me more than once. The worst occasion was where I was troubleshotting a performance issue on a database that had no indexes, no relationships and no constraints. Why? Because the responsibility for these components was handed over to entity framework and the application. It was utter chaos.
I don't think you could blame EF for that. It is the people using it. I'm assuming it if they didn't use EF and those same people designed the database it will still have no indexes / relationships or constraints.
Issue is most users of EF will define a class like this
public class Customer
{
public int CustomerNumber { get; set; }
public string CustomerName { get; set; }
public string Region { get; set; }
public bool Active { get; set; }
}
and then a database person will come along and wonder where there are no keys, all the fields are nvarchar(max) and all the columns allow nulls.
Whereas a better way to setup that class in an EF Code First scenario would be like so.
This will set the CustomerNumber to be a Primary Key and it will
public class Customer
{
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int CustomerNumber { get; set; }
[MaxLength(150)]
[Required]
public string CustomerName { get; set; }
[Column(TypeName = "char(10)")]
[Required]
public string Region { get; set; }
[Required]
[Index]
public bool Active { get; set; }
}
September 29, 2017 at 9:47 am
To be fair, plenty of people use tools (ErWin, Er/Studio, Visio, SSMS, etc.) to design:
create table customer
( CustomerId int
, Customername varchar(1000)
, Address varchar(1000)
, City varchar(1000)
, State varchar(1000)
, Country varchar(1000)
, NonUSProvince varchar(1000)
, PrimaryContact varchar(1000)
, PrimaryContactEmail varchar(1000)
, SecondaryContact varchar(1000)
...
)
It's not the tools, it's not the framework, it's not the job description. It's the knowledge.
Viewing 15 posts - 16 through 30 (of 35 total)
You must be logged in to reply to this topic. Login to reply