i'm starting a project about a social-based application, so i need to track users actions in time. To avoid an Epic-Sized table, i'm thinking about create a table for every single user, and record actions by user.
I've never heard about links of this type (row to table) and i don't know where to find some documentation about this particular argument.
About this, my boss wants to use Drupal for this project, someone have infos about this kind of structure in particular in drupal?
Hmm...maybe you should go for some "lower level" solution instead of Drupal. Drupal is CMS and if you make website Drupal's way you won't have freedom defining your tables the way you like. It's more you have one table defining some common (default) content type fields and for any new you add Drupal actually creates new table so you end up with some complex database structure.
Of course you can manually create your tables and use them also manually instead of using drupal's nodes and views and stuff, but then...what's the point of using Drupal?
So, IMHO some framework or even plain PHP would be more suitable for your project.
Related
Is there a way to create a new database in an ROR app automatically.
What I'm trying to do is create a new database for each new user that signs up for my site. so if the new user sign-up is successful a new database with some empty tables will be created.
Ever new user will get a new database and ever new database will be the same tables inside of it, but the information that each user will store will be different.
the reason I believe I need this due to if the user no longer want to use my system I can provide them the information that they stored on my DB and then drop the DB and tables with great ease
what I'm looking for is something like the mysql_create_db() in php
Dont you think that you are making a simple system complex? The way you are thinking is not scalable. For example, if you have thousands of user you have to create same amount of database tables!! Where most of the tables might be of no use. That is definitely ridiculous...
If you just want to achieve the followings
Each user will have his own data.
User may want to export data.
If users close his account you will delete all his data
then you better think the whole as a single application with a single database. Design your database accordingly and better look for the best DRY practices of rails to implement that.
This is not a good way to store users in a relational database, especially when using an application framework like ruby on rails which depends on your following convention over configuration.
Have one user Model and use the Devise and then Cancan gems to manage roles and permissions. There's no need to reinvent the wheel here and that's just what this would be doing.
If there are other considerations such as size or performance, please spell them out in more detail. The reasons you give (ease of management) would not be a good reason to go down that path.
It's an interesting idea and has uses in other areas, but really not so good for your standard user tables.
I am making a site in django [mysql] that will have to be scalable, so my question is what is better for multiple users with same kind of data
have a db per user , or have one big monolithic db?
Please advice of the design pattern preferred for this?
thanks!
Normally, You use a single database for multiple users with the same table schema, unless your requirement makes you create multiple DBs. Especially, if you have the same kind of data for each user, you must handle access rights and other things in your application side, not in your database side.
Django hava a nice User authentication/authorization system that lets you define permissions and lets you control user access rights (creating a new record, updating an existing one and deleting one) for each type of data that is represented by a table in your system. Also you can define custom permissions to control access rigts as you wish.
Separate databases are almost never the correct answer but there are cases in which it's appropriate. Unless you have very special needs, and in absence of any real description of what your project is, a single database is likely to be the correct decision.
I am making a semi-simple web application for my mother using php, mysql, and javascript.
She is a teacher, and this wil allow her to manage various components of her lesson plans.
For each component there is a table, and for each component that can contain another component there is another table that holds the relationship. (That table type has two columns each has a foreign key to the related tables)
I am nearly done, but she now wants to allow her friends to use this, I don't care too much about sql injection, but I would like to implement User Control so that only users that create a component can view and edit that component.
I also want them to be able to make public components, so that users can copy components to their own dataset.
My question To implement the user control should I have each user have there own database instant, or should each table have an owner column and column for public/private status, or is there another alternative that I have not thought of.
An issue that I see is that it would require additional mysql query when creating the relations between components because I would need to check that both components user tag matches the current user.
Any feedback/suggestions are helpful
Update The only people using/accessing this will be other teachers, that will be developing their own lesson plans
I would certainly implement this within the same database. Having a different database for each user is not a good solution in this case. Think, for example, how you would build a search function if each user's data is in a separate database will clashing UIDs. It would be a nightmare. Separate databases work where each database serves a separate application and there are precisely zero relations between the data in different databases.
So that brings you on to how to implement it. This will depend on your model. Will each lesson plan only ever have, for example, one and only one owner? If so, then adding that info to the components table might work. Or else you might need a separate table to define ownership and hence access to the different components. Either way, I would make sure the access logic is decoupled and encapsulated in your application to make sure you can change it in the future. Imagine for example you start with a simple, single-owner model but the site grows and grows and soon groups of people all need ownership/edit access to components.
I am developing a web application in which a user can Create a table in data base. I am thinking on taking the attribute names and table description from user and put them into SQL query and execute it. But the drawback is that if this application is installed somewhere else all the db connection parameters have to be changed secondly it will be hard coded. Or is this the approach in software industry?
Another approach I can think of is taking all the information about creating a new table from user and inserting them into one table and have some kind of trigger on this table which creates a new table everytime when insertion is performed into the first table.What would be the SQL Script for such thing if my approach is correct?
I am using SPRING - MVC, Hibernate, MySQL, REST web service
Please correct me if I am thinking in wrong direction. TO be honest I am not clear on how I am going to do this.
Thanks
This is risky, since a database schema with a vague and ever-expanding schema will become difficult to manage. Your problem isn't how to manage the credentials, which you would have to handle securely whether users were creating tables or not. Your problem is why it seems necessary for users to create tables.
Are you building an interface to manage arbitrary databases? Maybe phpmyadmin would give your users everything they need.
Or are you doing something not quite so general purpose and open ended? Perhaps with a sufficiently rich table design, you can give the users what they want without requiring that they build their own tables. What information do users have to put in a table that it looks like they need to build their own?
If you are more specific with your objectives, we could be more helpful.
I'm in the process of setting up a new WordPress 3.0 multisite instance and would like to use Sphinx on the database server to power search for the primary website. Ideally, this primary site would offer the ability to search against its content (posts, pages, comments, member profiles, activity updates, etc.) as well as all of the other sites that are a part of the network. Because we'll be adding new sites to the network on a regular basis, I'd like to be able to dynamically add those newly generated tables to the Sphinx .conf file (instead of editing the file and reindexing every time we add a new site).
Unfortunately, MySQL doesn't seem to support wildcards when specifying the table(s) in a query string. The best solution I've come across for grabbing a dynamic set of tables is grepping but I'm pretty certain I don't know how to do this within the .conf file (unless it's possible through magical sorcery).
Is it possible to dynamically specify tables to add to the Sphinx index? Or is this going to cause such performance issues that I'm using the wrong tool?
You could try to dynamically modify the .conf file instead.
You could query from a MySQL view that aggregates the many tables. You'd have to recreate the view with each change to the list of blogs, but I believe that all the hooks exist to support that and it should be easy enough to construct the view query.
The bigger problem may be in trying to find a suitable unique record ID for the posts in Sphinx. It has to be a straight INT, but the post IDs from the different blogs will collide with each other.
I think you can create triggers (INSERT/UPDATE/DELETE) in MySQL on the interested tables (e.g. posts, comments etc) and migrate the data to centralized global tables that are indexed by Sphinx in real time.
The point is how you can create those triggers automatically? Either you can run a cron job to scan for new tables in MySQL, or I believe you can write a simple Wordpress plugin that hook when a blog is activated.