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.
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 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?
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 find myself very frequently taking the decision between storing a object in the data store more appropriate to its nature (Events, Documents, Graph, etc) or just sticking to the relational database and moving on with my life, and i bet some of you do too.
I'd like to know what criteria you use to take this decision, for example, when is using NoSQL with little data is "premature optmization" and when it is "good enginneering"...
So, When to use the best data store and when to stick to relational?
I see a lot of questions with the nosql tag that include the following:
They want to mix RDBMS and NoSQL systems.
They think NoSQL for large data out performs RDBMS always.
They believe data modeling is always easier with NoSQL.
From personal experience I would consider the cost of discovery when picking a new database.
It is far from easy to move data between relational stores and NoSQL. It's definitely not always intuitive how to model data when working with a document store. Also some of these databases are so new that their query optimization is no where near a relational system.
The things I mentioned above might not seem like a problem when you're doing a proof of concept or working with small amounts of data.
My recommendation would be to not let the hype get to you when picking a solution.
(I've worked with production implementations of Mongo, Couchbase, CouchDB and Redis.)
I'm working with Oracle and Couchbase(nosql document-oriented DB). I think that the use of the NoSql in most cases it is easier and less expensive. Every NoSql DB is a mechanism for solving a rather small range of tasks, and if under your task suited one of them, using NoSql solution will be more optimal than using monstrous large Oracle or MSSql Server. Ofter we use not more than ten per cent of the capabilities of these powerful databases, but not because we know them not at a high level, but because we just don't need all of leeway that they provide
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've been researching on SQL Cursors recently and a colleague of mine said that Cursors are best used for auditing. I tried to look for materials over in the internet but no luck.
Can anyone explain why Cursor is good for auditing despite its disadvantages?
Like any task, it's about picking the right tool for the job. Some disparage the use of cursors due to obviously bad examples of their use, but cursors have their place. They are particularly useful for subsetting data and for reducing code redundancy:
Primarily, I use cursors to perform tasks on subsets of very large datasets, ie, banking data. With billions of records there are some operations you wouldn't want to do all at once, so looping through by day is a good option. There are other methods of iterating through subsets, but a cursor performs well at this task, it's still set-based operations, just on smaller sets.
Cursors are also great for looping through multiple tables/fields in a database, no need to re-write a procedure for multiple tables if it's going to be doing the same thing in each table, or if you are consistently working on a variety of databases. For example, I had need to analyze a multitude of various log files generated by multiple systems, but they all had date and ip fields. Trivial to have a cursor loop through each of the tables and combine all relevant data into one spot.
I wouldn't use a cursor to perform row by row actions unless necessary, and while I can't think of a use-case off the top of my head I'm sure they exist.
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.
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 was at a .NET development group meeting a couple weeks ago and the speaker was extolling the virtues of NoSQL and how even relational data doesn't have to be stored relationally if you just index lots of data. So, my questions are: was he blowing smoke? How does one craft an index to be more efficient than the last? Does indexing just logically store the information in a table in a logical format i.e. alphabetically?
Well relational data is needed more for data integrity than indexing. Speed is not the only consideration when choosing a database. SQL Server and other enterpise databases can perform very well if they are designed by people who know what they are doing. Unforuntately most relational databases are designed by data amateurs and their performance reflects that.
NoSQL databases and relational database are used for different things. I would never consider putting a financial application in noSQL for instance because of the need for data integrity and internal controls to prevent fraud and ensure records are consistent and correct. However a website where data quality doesnt matter so much (think Google - who would notice if they failed to serve up every single website that mentions Bill Gates in a query) then yes it is a good choice.