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 8 years ago.
Improve this question
There is so much conflicting and confusing advice all over the web about this. And I would like to settle this for myself and for any one who will be looking for such information in future.
Question is — Will Entity frame work work well with database that has tables with no Primary keys.
Detail : I have a database and it has lots of tables that don't have a PK specified. Call it bad design or whatever, but there is nothing I could do to change the schema now. I have to work with it. And we would like to use EF because we like MS and we work with MS tools all the time. We sleep much easier knowing MS will keep updating and supporting this EF, with its full attention in future. Okay here now is my burning question which I have researched excessively on this website and others. "Can I use EF in my project fully knowing that my DB has some tables that will never have PKs" . Part of the problem is we really want to use EF for ease of use and we being MSphiles.
I have heard lot of advice ranging from:
It wont work.
It can be made to work.
Not a big deal at all...
That's where it gets really sick. Please advise.
Well, it largely depends on how you intend to use it. Without a primary key, you can't have referential integrity. So, in effect you can't have automatic lookups of subtables and such.
You can do manual joins of tables, and that should work.. but that severely limits the functionality of EF.
But here's the thing, nothing we say can convince you. What will convince you is doing it yourself. Build a test database, and a test app. Setup your EF database. See if it works for you.
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 2 years ago.
Improve this question
So for context, I picked up MS SQL Server because the job required it. Currently, I'm able to do basic querying, and joins.
I hit a roadblock when I researched on how to improve, because the information seems to be overwhelming.
For example, some threads say to learn more about Database Administration while others seems to suggest that pursuing a certification by Microsoft is the way forward. Then I came across Data Engineering which is apparently different from Database Administration.
From what I gather, it looks like I should be working towards becoming a Data Engineer or Database Administrator. However, I'm not sure how I can go about it from where I am currently.
I just want to get better at it, and I'd love to hear what you guys feel is an appropriate way forward.
Thanks guys!
Brent Ozar to the rescue! While you are there check out the many resources they have on their website.
Go to StackOverflow and dig through some of the SQL questions and try to answer some. Even if you don't figure it out you'll learn a ton by trying.
People hiring Data Engineers are usually looking for formal training and education and you might not get far self learning. The name Database Administrator is a bit of a misnomer. Many places use Database Administrator and Database Developer interchably, especially places with heavily data driven systems where most business logic in the database. If you are interested in working with the data, and structuring the data, you probably want Database Developer, if you prefer maintaining the system, performance tuning and such then Database Administrator is the way to go. But like I said there is quite a bit of overlap with both roles.
Getting Into a Database Administrator Position
https://www.brentozar.com/archive/2008/05/moving-from-help-desk-to-database-administrator/
How to Get a Junior DBA Job – Part 1
https://www.brentozar.com/archive/2009/04/how-to-get-a-junior-dba-job-part-1/
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 years ago.
Improve this question
Often we come across some small insignificant (debatable) tables left out as stand alone. Although they are used in joins (sparingly) but still developers don't bother to relate them.
May be too many References made the inserts slow.
This leads to this question :
As a thumb rule should we relate all the tables in the database ? If no then where to draw the line?
thanks
Foreign Keys are not always a negative impact to performance, they can be a positive impact as well. Database relationships do more than just ensure referential integrity, they also help teach SQL Server about the nature of your data. The fact that two fields are related can give clues as to the cardinality of your queries and thus the optimizer actually takes these relationships into consideration when it's estimating the cost of your query.
In my opinion, if two fields are related in your database, they should have a defined relationship. In general, the more you can teach SQL Server about your data (not just relationships, but CHECK constraints as well), the better it will be at generating efficient query plans. Of course like anything in SQL Server, there are exceptions to the rule, but if you want a rule of thumb, I would lean toward defining all the relationships.
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 8 years ago.
Improve this question
I am old school and new to MVC. I like the MVC that's more focus on action. But MS has bundled it w/ EF together, it's hard to not to use EF nowadays.
This is what I thought:
1 - RDBMS stored proc/package suppose have better performance over LINQ. For instance, SQL Server Transact-SQL supports paging now, compared with LINQ, TSQL definitely has better performance. So LINQ is only good for people don't know TSQL or PL/SQL in terms of performance.
2 - I've tried using LINQ w/ stored proc. Thought it works but has many limitation, for instance, .dbml files are strongly-typed, it prohibited any attempts of re-formatting the data, such as adding an anchor to a field of display. Well, one might say you're not supposed to do so. Let me give an example, business wants to make a column clickable in a grid. There are a number of ways to implement, one of the quickest is to embed an anchorto the column returned from a stored proc, very little change on the UI. Hence QA just needs to test a few. But using EF as the foundation, anything based on this model/class must QA again.
3 - Model-first or Code-first wouldn't get a nice normalized large-scale database implementation, this is because if a developer doesn't know TSQL he wouldn't be good at RDBMS design.
4 - This is the most important issue: in an enterprise environment, we developers can NOT dictate schema and table definitions. Even with DB-first approach, sometimes we don't even know where it comes from. But that's what EF is good about, right? You might say. Imagine EF detects all schema and what returned from stored proc, then builds all data-layer/class for me. Great, but there is a need for a real-time median price which is not in the database at all, we add it in w/ some customization code. It will be gone if another scan and detect is needed because our client requests something causes a tiny change in the database. How do we avoid this hassle of losing customization code?
5 - Sometimes we need to run "update-database" command in the package console so EF can work. It's almost impossible to explain to Operation and DBA that they are harmless during release.
However, as EF is getting popular there must be a new-school way to make it work. Can some experts educate old-school please?
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 8 years ago.
Improve this question
I am using redmine for project management and issue tracking.
I was looking at the database tables and the underlying structure and was wondering if anyone who is VERY experienced with database architecture can comment on the structure.
I am concerned that once there are many users and hundreds (or thousands) of projects (each project containing many issues, with each issue containing many messages, etc.), the database structure could possibly turn out to be a weak point.
How is the performance impacted by this design?
I would like to hear about the Pros/cons of how the tables are laid
out and how the data is separated or normalized, and whether or not
it might be worth re-structuring.
What would be the benefits of
separating the data out to more tables (with less columns per table)
The database structure looks typical for an issue/project tracking system. If you can come up with a better structure, I would be very interested in seeing it :).
What you have to remember is that applying normalisation rules are all fine and dandy but if you apply it too much then sometimes you may hit performance problems (and the dreaded de-normalisation hacks start to creep in). In other words, there's a balancing act to be done between some normalisation and hardcore (too much) normalisation.
You would have to have a good reason to re-structure that database model. For example, it could be that for some particular query the database design does not serve the answer in an efficient manner. You could then start asking yourself what other table(s) could be created that would hold the data that I need in an efficient manner for optimal query performance. Also you could ask yourself what other indexes could be in place which will allow for optimal performance.
The fact is that until you have the very high number of users and projects and issues in this database as you predict it is hard to answer those questions. Maybe you could generate the data for some fake users and projects and test out the database to backup your concerns? Remember the adage of Professor Donald Knuth: Premature optimization is the root of all evil.
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 8 years ago.
Improve this question
I am in the process of designing a database for the first time outside of the classroom in order to make a future java application work with complete desired functionality. As I am trying to design entity relationship diagrams and tables, I find myself always thinking about my java project that is required later. I am beginning to wonder if this is making me more confused and if I am making this more difficult for myself; I am beginning to get nervous that I might not be skilled enough yet to pull this off.
Should I just focus on producing the most normalized database I can and trust that it will allow for my application to do everything it needs to do?
Or,
Should I definitely be keeping my future application in mind with each step of database development to ensure total functionality?
Edit: I would also appreciate any recommendations on free database design tools.
Databases are notoriously hard to refactor, so if you know about something you haven't gotten to yet but are definitely going to do, you need to consider that in your design. This is espcially true if the future something (For example reporting) is going to need to look at lots of records or is going to need moment in time data as opposed to doing calculations on the fly. This is the difference between storing the cost of an order vice calculating it based on current prices for instance. If you just look at the order process, you may thing it is ok to just calculate the price, but reporting will need to know what the price was at the time the order happened or the financial records will be messed up.
You might read this:
What are the general guidelines and best practices to keep in mind while designing database for an application?