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 4 years ago.
Improve this question
I wonder what the best practice is to deal with a data model like this:
We have 3 entities:
Role
User
Permission
Note that the entities are represented as java classes and will be mapped to a database via hibernate, anyway I think the question could be answered without having knowledge of these technologies.
There is a many-to-many relationship between Role & User and between Role & Permission.
Is it ok to have a bi-directional relationship here? So, that you can ask Role to give you all his members and to ask User to give you all his roles.
It's very comfortable that you can ask both entities, however one drawback is that whenever you remove a relationship you have to manage both entities.
E.g. if you remove Role from a User you have also to remove the User from the Role. This can be quite annoying if there are many of these relationships. Therefore I would like what the best practice is.
I try to avoid bidirectional relationships. Instead replace one direction with an explicit query in you DAO/Repository. Keeps the model simpler and if done correctly via interfaces the application clean of circular dependencies
Is it ok to have a bi-directional relationship here? So, that you can ask Role to give you all his members and to ask User to give you all his roles.
Yes. If you actually need the navigability in both ways, then there's no reason to prevent yourself from obtaining it in the simplest way possible.
one drawback is that whenever you remove a relationship you have to manage both entities.
This depends on the implementation, one could implement the data model in a way that would synchronise both "ends".
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 9 years ago.
Improve this question
I have a project which is using NodeJS and I have different entities for example, people and places.
I need the ability to find both types of entities by location together so what I was thinking of doing is having an index on a field called, type, for example, which would be either person or place and make use geospatial indexes, does this sound a good way to do this or is there a better way?
I will probably need a lot of joins too, so should I use MySQL alongside MongoDB and use MongoDB just for delivering the location based queries?
Thanks
This question is a poor fit for stackoverflow, but here's some radom bullet points:
PostgreSQL supports both joins and geospatial. I'd pick that first personally lacking other details warranting a different data store.
A totally valid option would be to keep people and places separate and query multiple collections as necessary. However, if you need to sort the results, then yes best to throw them in the same collection.
You could also keep people and places in separate mongodb collections but have a mapreduce job translate them into a locations collection for search purposes.
Generally, there are lots of ways to do this and the best one depends very much on the specific aspects of you application. Reads vs writes, data stability, data size, query load, etc, etc.
My broad word of advice is start with the most logical, easiest-to-follow, straightforward data organization (separate collections), and deviate from that when you understand the specific pain you have and how doing something more complicated or unusual will be an overall win.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is it possible/reasonable to have a voting system on NoSQL database ?
For example how would be possible to store StackOverflow question into the NoSQL database.
I can easily imagine almost everything except how the relation will work between question/vote/user. Everything else can be stored in one document, like tags, comments(assuming there are relatively small amount of comments on posts, in my case I will not have comments anyway), user information, etc... but can't imagine how to store user votes as document will become huge. One of the options is that I can have votes stored in separate collection/document, but it will mean that while loading a question there will be a need to send another request to check if the user have voted for a question or not.
A good reference is the MongoDB documentation on Embedded documents vs Referenced documents, since those are what you seem to be referring into your question. There's no perfect solution, as both have their trade offs. You just have to make the best decision based on the type of operations/queries and their frequencies that you're expecting to be run on your database.
Honestly, until your database starts getting some serious traffic, the difference between SQL and NoSQL won't matter. Pre optimization can end up doing more harm than good, so I would just go with the one that is easiest to get deployed and you're more comfortable with to begin with.
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 5 years ago.
Improve this question
I've been developing a small database for my summer internship and I need to write a manual/documentation for it aimed at both users and developers for future use. Thing is...I have no idea where to start or what information to include. Many people I work with have no idea what databases can do so I need to keep it as simple as possible. The database is implemented in Access and I experimented with the database documenter but I think that is overkill. Is there some kind of documentation standard that I can follow or anything of that nature?
As a starter for ten, I'd have thought that the user documentation should be task orientated.
(i.e: How to achieve 'X'.)
In terms of the developer documentation, defining the meaning of any non-obvious fields in your schemas, how they're used and the relationships between different tables, etc. would be a good start. (I'm presuming your VBA code is well commented, etc.) You may also want to examine the existing "Documenting Visual Basic with Doxygen" question/answer.
Just straightforward english if you are explaining a process.
If you have a series of Macros do a document highlighting to code used in each macro and the order it should be employed. This could aid someone down the line if they are trying to automate the process.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
Our development database now has 263 tables. During development we only work with a few. Is there anyway to organize all the tables into something like folders?
There is no way to organize tables hierarchically that is meaningful to MySQL.
As others have noted, you can maintain separate schemas (in MySQL, databases), or you can develop and use a table naming structure that organizes your tables in a way that is meaningful to users (but is still not meaningful to MySQL).
The only thing that occurs to me is to use different databases for different sets of tables. See CREATE DATABASE
I don't believe there is a way to organize tables other than to move them into other dbs. What you could do is prefix the ones you use frequently so they are always at the top (this only works though if you have defined constants for your table names for just such an occasion so you don't have to trudge through your source code changing every instance it is called).
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 4 years ago.
Improve this question
If I have a business object with 50 fields, and I need to populate something like a drop down list or gridview with only 3 fields from the business object to allow quick browsing.
Is it best practice to load the fully populated BO then just grab the few required fields in your presentation layer ?
It seems inefficient to populate a collection of Bo's that size but the only other ways would seem to be to return partially populated BO's with just the fields you need for a particular UI which would be hard to manage if you have alot of similar UI requirements, or make a baseclass like MyBusinessObjectHeader that contains the fields then make MyBusinessObject inherit it and implement the rest of the fields but this would tie it your UI too much it seems.
Whats the best practice for this type of situation ?
I make a separate readonly list of readonly digest objects (or structs) that are lightweight and cannot be manipulated. The collection can be customized for whatever needs you might have as normal. Retrieval of a full object can be used by passing a "digest" object to a type conversion, or factory or constructor - whatever techniques you are using.
Note that this is an optimization which only happens when a collection of full-blown objects is simply getting too slow. It can easily be created at that point. Generally such classes are not created until necessary.
There are a lot of frameworks out there that do this sort of o/r mapping you're talking about.
You're trading a little more overhead for ease of use and robust configuration.
See Hibernate or NHibernate if you're using .net.