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
I'm curious if there is a preferred method for storing assets in a database, that is, the path to the files (I'll be using postgres if that matters). I'll have PDFs, Videos, and audio files.
Should I create a single table and have a 'type' field, or does it make more sense to create a pdfs table, videos table and audio table?
Thanks
This is a pretty common question when it comes to designing database, and there's no one-size-fits-all answer. It really depends on which of the two setups is going to be most useful to you. Or, which setup is going to cause you the least problems.
Logically, do you expect to deal with each resource differently? Or do you expect to treat them largely as subtle variants of the same type of thing? For example, are there relations or constraints in your data model which refer to one specific type (e.g. resumes.pdf_file_id would be specifically for a PDF file, and having it potentially be an mp3 wouldn't be very helpful). If yes, I'd go with separate tables.
On the other hand, if you want to be able to see all the attachments a user has uploaded, it would be easiest to just query a single table, e.g. SELECT * FROM attachments WHERE user_id=?, instead of dealing with selecting from three separate tables.
There are middle-ground options, though. You could have the separate tables, but link them all to an attachments table which stores the S3 URL. Or you could use database-level inheritance to treat them as both separate and unified tables (this solution often seems perfect, but I wouldn't recommend it). Ultimately, the best choice depends on your use case.
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 6 months ago.
Improve this question
I am brand new to ios development and am looking for some advice on the best way to structure my user data and access it throughout my app.
Data is retrieved via HTTPS requests that query a database for the desired information. There are separate calls for the different tables containing information of interest. The returned data is formatted as nested dictionaries where the outermost key is the column and the subsequent dictionary is key-value pairs of the index and the table value. Example:
{"column1":{"0":"value1-1", "1":"value1-2", "2":"value1-3"},"column2":{"0":"value2-1", "1":"value2-2", "2":"value2-3"}...}
My primary requirement is that I will need to be able to filter this data by the innermost values (some will be dates, some will be numbers, etc). I would like to have the data in a format that will make this simple to do and will not cause delays as there is no limit on the number of possible rows.
I have looked into reconstructing a user-specific SQLite database with the information and querying that throughout the app as necessary. I have also explored dataframes as this app was originally developed in python - don't ask - and relied on pandas dataframes.
I know this decision will impact me heavily and am trying to do my best to make an informed decision. I appreciate any feedback and am happy to give more useful context that might be missing.
TIA
You can use SQLite database for persistent storage. This is ideal for your main requirement of filtering the data. You should also create a structure or a class modelled on your data to store and use during runtime. You can refer this for deciding between a class or structure.
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 6 years ago.
Improve this question
In most ASP.NET Mvc tutorials, you see people creating simple models and then scaffolding controllers with views, using Entity Framework.
In most tutorials you will also see that they create a new DbContext class which will have the DbSets. I understand that this is a good thing to do for educational purpose, to help the person understand how it works.
But the account system that comes with a default Mvc project always links to "DefaultConnection".
Some tutorials will also make use of the account system to advance further, but that means that at this point you would have 2 databases running to support your web app.
one for the account info
one for the details of your model(s)
Is this the correct way to work? or do most developers/companies just use 1 database for both of these?
My reason for asking is because i found this tutorial which uses both of these aspects and works on 1 database and it is the first time i see this being done.
There's no right or wrong way. You need to evaluate the requirements and time lines for your projects and decide which options suits you best.From personal experience, in all the projects I worked on, the account info and the models reside on the same database.
Remember that if you have two databases you will need to create two data contexts to access them.If the database needs to be moved to another server, you would need to move two databases and change the connection string in two places, also the maintainance and upkeep on the DB would need to be performed in two different places.It's really a maintainance headache and should be avoided in my opinion unless your requirements have some compelling reason that you should place account info into a separate DB.
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 currently have three models: Business, Charity, and Organization. A business and charity are both types of organizations because they share many similar attributes (e.g. address, hours, website, etc.) however they each have their own unique attributes. How should I best handle the creation of the models in Active Record? Use STI or Polymorphism? Or should I break out each one into their own model with duplicate information and get rid of the Organization model?
You can use both, so it is not necessarily an either/or situation. Most importantly, however, is how you will structure your tables and the logic surrounding them, which depends on how you are going to query the data, and how these elements relate to one another.
There is not enough information above to give you very clear direction on what to use. However, if after reading:
Rails Guides
How and When to Use STI
... the solution isn't clear, here are some simple rules:
if the types of objects you are using mostly have the same attributes but have different business logic attached to them (ie, the behavior written into their Model classes), then STI is a good baseline idea, but
if they have the same logic as well, it may make sense just to create them as a single class with a "type" flag (but not the attribute type, since it is only for STI)
As far as polymorphism goes, it seems like these Models are all very similar and interchangeable -- polymorphism is more useful for relating unlike things (such as comments and photos) to another Model (such as a FB post). In that case, using either a single table or STI and relating based on the parent table may make more sense.
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 8 years ago.
Improve this question
How to validate incoming data using stored procedures in real time? can some one explain this ?
You can, but I think this is a bad idea. Business logic does not belong in a database. It belongs in service code (middle tier of an application). The role of a database is to retrieve and save data, not validate it. At least not in the sense of applying business rules.
Now, you can do 'validation' in the database in the sense of check constraints and foreign key validation, but this would not be done in stored procedures. This is native support built into most modern database systems.
So, in my opinion, forget about doing data validation in a stored procedure. As I said, validation doesn't belong there, and, it's going to be much slower than putting that logic in a middle tier using C++, C# etc.
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
What advantages and disadvantages do you know of Ruby on Rails polymorphic relationships.
Advantages:
You can link anything to anything quite easily
Adaptable relationships help accommodating unforeseen circumstances
Very easy to implement relationships
Great for ad-hoc systems
Disadvantages:
Foreign keys not practical
Indexes include another dimension of complexity
Relationships between tables hard to identify when using STI
Database diagramming tools cannot interpret
Not always practical for join models
Strongly discouraged for systems where data integrity must be verified
I'm a big fan of using relationships of this sort for records that are attached to a large number of things as required, for example, a comment or annotation record which may apply to a wide variety of records.
It is not very well suited for situations where the relationship is exercised in a JOIN frequently. That is, the polymorphic association should not be in the middle of a relationship between records, but as something on the perimeter.