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 last year.
Improve this question
I am creating a website where the user has the possibility to upload content (pictures, videos pdf's etc.).
Each type of content has a different number of properties with corresponding values.
I have thought about making this design:
Is this the right way to do it?
Since each type of property has a predetermined set of property-names, should I make a relation between the two? Or would it be fine to handle this in code instead?
Normally in a relational database you should use columns to model the attributes of an entity. So "Plan A" is to create PictureContent, PDFContent, etc tables in the database.
The design you are proposing is called Entity-Attribute-Value or EAV. It has some pretty serious drawbacks, but it is occasionally useful, typically when data sizes are moderate and you need change your metadata at runtime.
If you do need a dynamic schema, consider using JSON instead of EAV, which can easilly be serialized into .NET objects, or accessed dynamically.
Related
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 5 years ago.
Improve this question
Why do NoSQL databases want the data to be as flat as possible? Especially in the case of firebase. Can anyone provide read or write calculations to show the differences in I/O between relatively flat databases and relatively deep, multi-level, databases?
I what comes to Firebase Realtime Database, it's much more than performance, it's about information retrieval strategy.
You are free to save the ids of every liker of a specific post nested in the post structure, but if you feel you don't need to retrieve all this information every time you get a post (let's suppose you query a list of posts only to show as a summary cards), then you won't want to have it nested, but flat under a "post_likes/{postId}" node for example.
Remember that in the Firebase Realtime Database you can't filter out the nodes you don't want to receive. At the moment you retrieve a node, you get it all the way deep down the structure.
Think about the same example now, but for comments. The same thing apply, so we could structure our comments under a "post_comments/{postId}" node and only retrieve it when we are willing to show the comments.
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
Basically my application needs to dump data daily into a database. But for any data written down, there is no need to update.
Hence, is appending to csv or json file sufficient for the purpose. Or it will be more computationally efficient to write in standard SQL?
Edit
Use-Case Update
I am expecting to store one entry of for each particular activity count daily. There are about 6-8 activities.
It is exactly like a log in some sense. I would like to perform some analysis with the trend of activities for example. There is no relations between different activities though.
If say in some cases there might be a need for update, would that imply a proper database will be more suitable rather than text file?
It depends on the nature of the data, but there may be another style of database other than an SQL one which could be suitable, like MongoDB which essentially stores JSON objects.
SQL is great when you need entities to have relationships to each other, or if you can take advantage of the type of select queries it can provide you with.
Database systems do have some overhead and could have some gotchas you might not expect, like loading up a heap of crap into memory so it's ready to be searched.
But storing text files can have drawbacks, like it might become difficult to manage your data in the future.
It basically sounds like your use-case is similar to logging, in which case dumping it into a file is fine.
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
When relations between tables are created it becomes very difficult to edit tables, drop and re-create them. well I decide to leave creating relations for when the job is done and that time its not easy either and later some tables might need modifying again.
what is the best practice for creating foreign keys, and all other relations?
In big projects that I devide project to several small projects, well sometime in one of the smaller projects I see that I have to make a small change to previous small projects. and this ruins everything.
I always create relations when I create my initial database structure, and because it is normally (sometimes... once was...) designed properly, the relations don't tend to change.
What you may find eases any changes to the tables is to change one of the options
In Tools-Options, choose Designers - Table and Database Designers and clear the checkbox marked Prevent saving changes that require table re-creation
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I have a social networking system, and there are topics, tasks, questions, links, documents, videos and so on. I plan to put all of them to one table named posts, and there is one column name kind to identify. Is it a good design ? why ?
BTW:
1、I am using postgresql
2、I just think there are many repeated columns between them , for example: the title, the content, the created_at and the author
From your description it seems like all these domain objects have something in common. Otherwise you wouldn't even think about storing them in one table. Accidently or not what you have described is one of the techniques of mapping inheritance to relational model, called single table. The link above describes in detail other techniques and what are their pros and cons.
You can't index columns for which you want to perform search on it. Why do you want to put everything in the same table at the first place?
No. It limits these things to all having the same attributes. So if, for example, a "Link" needed a URL field, a topic, a task, a question, etc would all have to have one too.
It is NOT a good design with postgresql. Normalizing data in a relational database is very important.
You should consider using a NoSQL database system such as mongodb.
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 3 years ago.
Improve this question
Do you think it is alright from architectural stand-point to have ViewModel - View without Model for temporary things?
E.g.: I want users to input some paths so I can open some files later on. It doesn't make sense for me to store the paths anywhere just ViewModel and when the user clicks "Show all files" I then construct models of the files and ViewModels for View that represent them somehow.
So really my only model is the model of the file.
I think sometimes people mistake design and architectural patterns as hard and fast rules. We need to understand that these are just guidelines. One example of this could be the way different programming languages implement singleton pattern.
So I would say if you need the functionality of View Model to be bound to View but really don't require a model, there shouldn't be any problem in ignoring the model. I would suggest use these patterns as guidelines and not as hard and fast rules. Feel free to make minor adjustments wherever applicable.
But at the same time keep in mind that you are not violating the purpose with which these layers are created. It should not happen like we bypass the model and start querying the backend database directly from the View Model. As long as the basic principle of separation of concerns is adhered to everything should be fine.
Of course. If it suits your business process, why not.
But you could probably still use a model to have some sort of in-memory persistence of the entered paths.
Sure. There's no sense in moving the file-opening logic to a separate object just so that you can say you've done it.