What I want is that when I have looked up a user in a table, I want to list all the file urls that the user have access to. My first thought was to have a field in the table with a list of file URLs. However, I have now understood that there are no such field type.
I was then thinking that maybe ForeignKeys might work, but I am having trouble getting my head around it.
Another solution maybe is to have one table for each user, with each row representing each file.
What would you say is best practice in this case?
I am also going to expand into having shared files, but thought that I'd address this issue first.
Suggest you explore the JSON Data Type
2 tables: user and user_uri_permission? 2 columns in the second: userID and URI. When the User-URI pair is in the table the use has access.
Related
In my Firebase database, I have a data structure similar to this:
The post ID (1a3b3c4d5e) is generated by the ChildByAutoId() function.
The user ID (fn394nf9u3) is the UID of the user.
In my app, I have a UILabel (author) and I would like to update it with the 'full name' of the user who created the post.
Since I have a reference to the post ID in the users part of the database, I assume there must be some code (if statement?) to check if the value exists and if so, update the label.
Can you help with that?
While it is possible to do the query (ref.child("Users").queryOrdered(byChild: "Posts/1a3b3c4d5e").queryEqual(toValue:true)), you will need to have an index on each specific user's posts to allow this query to run efficiently. This is not a feasible strategy.
As usual when working with NoSQL databases: if you need to do something that your current data model doesn't allow, change your data model to allow the use-case.
In this case that can either be adding the UID of the user to each post, or alternative add the user name to each post (as Andre suggests) and determining if/how you deal with user name changes.
Having such relational data in both directions to allow efficient lookups in both directions is very common in NoSQL database such as Firebase and Firestore. In fact I wrote a separate answer about dealing with many-to-many relations.
If you can change the structure then that is very good because I don't think you are maintaining proper structure for database.
You should take one more key name createdBy inside the Post node so actully structure would be
{description:"Thus the post is here", title:"Hello User", createdBy:"Javed Multani"}
Once you do this, It will dam easy to get detail of user.
OR
Unethical solution,
You can achieve this thing like while you are going to show Post from post node of firabase. Definitely you'll get the auto generated postid like:
1a3b3c4d5e
now first you should first get only posts then inside the successfully getting data and parsing you have to get users and find inside the user by putting the codition like postId == UserPostId if match found take fullname value from there.
I'm and intern and I've been tasked with something I'm pretty unfamiliar with. My manager has requested I create a simple MySQL database using data from an Excel file(s) and I have no idea where to start. I would normally ask someone here for help but everyone seems to be really busy. Basically, the purpose of the database is to see what different object-groups relate to one another so as to keep things standardized. Trying not to go into detail about things not really relevant.
I was asked to first design a schema for the database and then I would get an update on how to implement it. Would I just start by writing queries to create tables? I'm assuming I would need to convert the Excel files to .csv, how do I read this data and send it to the correct table based on Object Type (an attribute of each object, represented in a column)?
I don't want to ask too much right now, but if someone could help me understand what I need to do to get started I would really appreciate it.
Look at the column headers in your spread sheet.
Decide which columns relate to Objects and which columns relate to Groups
The columns that relate to just Objects will become your field names for the Object table. Give this table an ID field so you can uniquely identify each Object.
The columns that relate to the Groups will become field names for a Group table. Give this table an ID field so you can uniquely identify each Group.
Think about if an Object can be in more than one Group - if so you will probably need an Object-Group table. This table would most likely contain an ObjectID and a GroupID.
I'm trying to do it like this:
Every single user can choose fields (like structures on MySQL) where this fields can handle their respective value, it's like doing a DB inside a DB.
But how can I do it using a single table?
(not talking about user accounts etc where I should be able to use a pointer to his own "structure")
Do something like: varchar Key where register something like "Name:asd" where PHP explode : to get the respective structure ('name' in this case) and the respective value? ('asd')
Use BLOB? can someone turn the light on for me? I don't know how to do something where works better than my current explanation...
I know my text is confuse and sorry for any bad english.
EDIT:
Also, they could add multiple keys/"structures" where accepts a new value
And they are not able to see the Database or Tables, they still normal users
My server does not support Postogre
In my opinion you should create two tables.
with the user info
with 3 fields (userid, key and value)
Each user has 1 record in the first table. Each user can have 0 or more records in the second table. This will ensure you can still search the data and that users can easily add more key/value pairs when needed.
Don't start building a database in a database. In this case, since the user makes the field by himself there is no relation between the fields as I understand? In that case it would make sense to take a look at the NoSQL databases since they seem to fit very good for this kind of situations.
Another thing to check is something like:
http://www.postgresql.org/docs/8.4/static/hstore.html
Do not try to build tables like: records, fields, field types etc. That's a bad practice and should not be needed.
For a more specific answer on your wishes we need a bit more info about the data the user is storing.
While i think the rational answer to this question is the one given by PeeHaa, if you really want the data to fit into one table you could try saving a serialized PHP array in one of the fields. Check out serialize and unserialize
Generates a storable representation of a value
This is useful for storing or passing PHP values around without losing
their type and structure.
This method is discouraged as it is not at all scalable.
Use a table with key-value pairs. So three columns:
user id
key ("name")
value ("asd")
Add an index on user id, so that you can query a user's attributes easily. If you wanted to query all users with the same properties, then you could add a second index on key and/or value.
Hope you are using a programming language also to get the data and present them.
You can have a single table which has a varchar field. Then you store the serialized data of the field structure and their value in that field. When you want to get the structure, query the data and De-serialize that varchar field data.
As per my knowledge every programming language supports serialization and De-serialization.
Edited : This is not a scalable option.
I have one table like this
account_id (INT)
inviter_id (INT)
Now, logged in user with account id 5 wants to see the logs that related to all of his invitees, directly and indirectly, as this table may represent nested hierarchy of unlimited depth.
How would I do that with MySQL?
I accept a solution in PHP/C/C++/C# (:
Actually I've looked for it here and at google and couldn't find anything for that particular case, as everyone try to have nested menus at their website and ask about it.
I've been thinking about simply querying for all accounts in the database (there are about a few hundreds) and from there simply build a tree, or something, but then again I have to stay synced with the database.
So to stay synced with the database I've thought about querying the COUNT() of the accounts in the table, but, what if I need to change an inviter'd (maybe deleting one)?
Anyway, I could appply the rule of "not changing inviter" - if I'd do that, then COUNT() would work I think - is there any better approach to that kind of issue?
you can take a look at my answer(s) here if you like:
Print hierachical data in a parent child form unordered list php?
or here:
Mysql Recursive Stored Procedure...Limit 0 reached...can't change the max_sp_recursion_depth variable
or here:
Multi-tiered Comment Replies: Display and Storage
or here:
MySQL Hierarchical Structure Data Extraction
hope it helps
Check this out, this might give you some ideas: http://www.ideashower.com/our_solutions/create-a-parent-child-array-structure-in-one-pass/
I'm developing website in which will be categorized advertisements. In each category will be possible different fields of input (example: for car there will be motor size, for cat there will be a race). So I'm thinking how to build database to manage this (I will use MYSQL database). One way you can see in attached picture, I know that also is solution to create table for each values datatape, but I'm wondering that it will slow down a website. This solution which is in picture will generate empty fields in sp_advertisement_value table what isn't good also.
What is in your opinion the best solution? Maybe there is something else?
p.s. Here is a link to database market.
You can store it like name/value pairs (more or less same to what you is described in the image you attached).
A simple schema would be a table having two columns name and value. Instead of having a column for each data type like value_int, value_string etc. have one single column value who's data type can be varchar (or Text as seems fit to you). You can do all the data conversion in your application code as per your needs.
You can do some normalization here too for instance instead of saving name you can make a separate lookup table named parameters having id, name and other related information and have the parameter_id in the table where you are storing parameter values.