I have to make a "virtual filesystem" in MySql (using asp.net as the web-application). It's not going to be very complex, probably maximum 2-3 subfolders "deep", with maybe up to 10 files in each folder. Each user will have their own folders and files after they log in. The admin(s) should be able to make "templates", and assign a template to new users. A template will have a few folders and files in it. And this is what I'm scratching my head on how to make. I think I'm at least close to design the tables, but I'm not sure. Here is the tables I've created so far:
Files
ID
Name
ContentType
FileDataSize
FileData
Parent_Folder_ID
Folders
ID
Name
Parent_Folder_ID
Users
ID
Name
Email
Password
Templates
ID
Name
User_Templates
User_ID
Template_ID
Am i on the right track here? Or am I missing something?
This looks pretty simple, and this will probably just work for your purposes.
The only problem you will run into, is that you will need several queries to determine the the full path for a leaf node.
The easiest way to solve this, is to actually store the full path in a separate column, such as:
folder1/folder2/node
Not as pretty, but certainly the absolute easiest to deal with.
Alternatively, you could use the preorder tree traversal algorithm, but this can be more complex, and while fetching sub-tree's is fast, updates may be incredibly slow.
Related
I'm considering storing a working directory (i.e. recursive/nested folder/files) into a mysql database.
The idea is to have a 'projects' table, and a table that contains all folders / files with their corresponding paths in the tree (varchar).
Querying a project should return folders and files as a list of String paths (+some meta-data) that I will use to build the tree at the client.
I should mention that the 'file' records in my working directory are meta-data that represent json files in a mongodb datastore (they describe webpages as complex nested json). File records will be queried more frequently than folders (they don't get queried at all), and will be linked to other tables. Files have a different meaning for my app than folders, which are merely important for my working directory.
My question is what would be the best option:
Store files and folders in separate tables
Store files and folders in the same table (the records will be near identical), and use a FK on a joined table with 2 records "file"/"folder"
Short answer: "classic" relational databases (including mysql) are not very good at this. Here is a good link: Managing hierarchical data in mySQL
On the other hand, Wordpress is an application that does many of the things you're trying to do - and it does it all in mySql (or equivalent RDBMS).
Look here, look especially at the "taxonomies" section.
Another approach might be to look at a graph database, like neo4J.
'Hope that helps ...
I have seen many questions related to database migration, but none which clearly state: When editing a database which of the tables do I actually need to edit?
As a force of habit I edit the entire mySQL database, and usually that works out. (However on occasion this can mess up URL left in user comments for instance.) However it would be good to know specifically which tables I actually need to edit in order to complete a migration correctly.
EDIT: I already understand how a migration works and which tool to use, and I have read the codex entry on migration. I am not having a specific problem migrating.
This is really more of a best practices question.
What I am looking for is a definitive list of what tables I can exclude from my search and replace. For instance I know that the basic URL info is in wp_options, I know that (some) image paths are stored in wp_postmeta. Basically I want to exclude every table I possibly can, while still preserving the site's widgets, images, settings, etc.
The only references that HAVE to change are in the wp_options table. One is the home url and the other is the siteurl. These will allow you to log into the admin and view the frontend. However, you will still have to update your permalinks and rewrite rules using the admin.
I would still suggest an automated solution, however. I use this tool to find and replace database references. It is specifically made for wordpress, but it will work for any database. It also will allow you to select which tables to update and will work with serialized strings so you should be able to avoid errors in the comments section.
Simply drop the file on the root of your wordpress install and run through the prompts. Make sure to deselect the wp_comments and wp_commentmeta tables. Also, make sure you remove the file on production as it presents a potential security threat.
UPDATE BASED ON COMMENTS
Other than the two spots above, there are several places in the database that URLs are stored. Most plugins will store their options in the wp_options table. Typically, plugins will also serialize the data to avoid a ton of queries. You can't simply change the URL in the serialized data however, because there are length references in the serialized string. So if your current URL is 15 characters long and the new one is 20, you need to update the URL and the string length too. If you don't, PHP will just ignore the value. I believe this is a security measure to avoid code injection.
For assets in the media section the URLs are stored in the wp_posts under the post type attachment. If you are hardcoding absolute links in your posts, you may need to parse those as well (if this is the case, you can probably just parse the entire table). If you are using any sort of custom field plugin or doing anything with post meta for URLs you are also going to want to go through wp_postmeta.
One other thing to mention is that some plugins will add their own database tables. These are obviously on a per case basis, but a good rule of thumb is to try running a query for "%http%" in any string columns to see if there are hardcoded URLs. Here is the query I will use:
SELECT * FROM `table` WHERE `column` LIKE '%http%'
Download the file from the following link http://interconnectit.com/products/search-and-replace-for-wordpress-databases/.
Put it in the root folder and access the file and follow the steps and replace the urls.
I have been using it for quite a long time without any issues.
Hope it helps!
Thanks
Is there a way to create a file system like this. Whenever a new user is registered a folder with unique ID is created for storing images in the filesystem for that user. If he/she creates a new album for pictures another new folder will be created inside that unique folder for the user.
Thank U.
You can do that with server-side scripting. For example, with php you can create a new directory using the mkdir() function: http://php.net/manual/en/function.mkdir.php
Beware of scalability issues. I'd recommend you to add another level if indirection, that is, to store user directory in the table. At first you may create directory structure however you like, but when you'll have tens of thousands of directories at one level of filesystem, you could get into filesystem-level performance issues. Then you'll just reorganize your folders, move files, and update table links.
I'm looking to make a hopefully rather simple document storage system in sql 2008. We have a general idea of the elements we need, some meta data storage, filesteam, etc, but there are a few things we aren't quite sure of.
Specifically, we would like to implement a fake folder structure, as well as some (flexible) permissions. Permissions could be on a group level or by individual users, and should we should be able to specify no access, read, read/write, on either file level or folder level.
I'm not looking for someone to write this schema for me. But what I am hoping for is someone has resources that would cover these topics?
Thanks
~Prescott
I think you should go with the classic route of having a documents table that would hold the docs (If using 2008 or above look at FILESTREAM). The meta tables would then link to that.
Your folder structure could be achieved by having a folder table, the material table could then have a field to show which folder the material is in.
To get the sub folder levels you would just have a parent folder field in your folders table self linking back to the same table. You can then render that up in a treeview control in what ever flavour language you wanted
Have you looked at FILESTREAM Storage in SQL Server 2008?
I'm writing an online project asset tracker but I'm new to MySQL. What would be the best way of tracking projects, users, and assets for something like this? I have 3 tables for assets, users, and projects. Users should own projects and assets. Assets could be members of multiple projects, and projects should be able to be seen by multiple users.
The first method I figured would be to have a mediumtext field on each project with the id for every asset that it's linked to. Each asset would also have a mediumtext that will have every project id it's linked to. This is a problem though, since I can't really do a search without having to parse the text to find out the projects/assets it's attached to.
Another solution without parsing would be to have separate tables for the linking information, so for instance there would be an asset table with the asset id, project id, and userid that it's part of, and if it gets assigned to another project or user, there would be another entry into that table. This solution, though, will have assets that have multiple entries.
Another way of doing it would be to have the site create a table whenever a project is created, and that will store the asset and user information. Since there might be thousands of projects, this will crowd up the database pretty quickly, and creating tables is heavier on MySQL than entries, as far as I know.
I'm leaning toward the second solution. Is there anybody who knows a better way?
Quote:
have a mediumtext field on each
project with the id for every asset
that it's linked to
This is the worst design... maybe ever! Read up on database relations. Take an emergency crash course. Look at some example databases; MS Access has some pretty decent templates you could examine.
What you describe looks like it could be modelled with these relations:
project --- inf:inf --- users
asset --- 1:1 --- users
asset --- inf:inf --- projects
The many-to-many relations would go in a separate table.