How to create in Sql a table 10x100 with random numbers? - mysql

I want to create in my database 3 tables 10x100 with random numbers. How could this be possible? Also I want in Wordpress site to give the user the option to choose what table he wants.

It sounds like you want to serve custom data to a WordPress site. These should be two different questions. The first is how to create the DB tables you want. The second is how to display custom data on a WordPress page. Both of those can be handled by some introductory material. I think the heart of what you are looking for is the RAND() function.
https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_rand

Related

database schema for blog platform like blogspot in relational database

I always wondered How can design database for blog platform like blogspot.
for example for posts what is good design for medium size blog platform:
put all posts from all blogs in one table and use something like blog_id column for them.
every time new blog request come create whole tables that needed in same database, and name tables like post_blogId (post_1, post_2).
create separate database for each blog
I think number two is better but question is a platform that has 500,000-1,000,000 blogs must have 500,000-1000,000 tables for posts and also for comments..!! does it efficient??
what about choice number 4??:
use solution 2 but for something like each 500(what this number should be??) blog create separate database.
I really have no idea which one would work efficient :(.

Asking opinion about table structure

I'm working on a project to make a digital form of this paper
this paper (can't post image)
and the data will displayed on a Web in a simple table view. There will be NO altering, deleting, updating. It's just displaying (via SELECT * of course) the data inputted.
The data will be inserted via android app and stored in a single table which has 30 columns in mysql.
and the question is, is it a good idea if i use a single table? because i think there will be no complex operation in the sql.
and the other question is, am i violating some rules for this method?
I need your opinion. thanks.
It's totally ok to use only one table, if that suits your needs. What you can do to make the database a little bit 'smarter' is add new tables for attributes in your paper that will be repeated. So, for example, the Soil Type could be another table where there are two columns, ID and Description, and you will use it as a foreign key in each record in the main table. You need this if you want your database to be in 3NF.
To sum up, yes you can have one table if that's all you need. However, adding more tables might help save some space and make your database more flexible. It's up to you to decide! :)

Indefinite number of tables vs indefinite number of row with multiple columns

Which one would be better (performance wise and maintenance), a database which creates table dynamically or just adding rows dynamically?
Suppose I am building a project in which I let users to register. Say I have a table which store only basic personal infos, like name, dob, Date of joining, address, phone, etc. Say 10 columns.
Now is the tricky part.
Scene 1: Creating multiple tables
When a user complete registration, a message table is created. So each table is created for each users. The rows of each message table varies for each user.
In the same way there is a cart table for each user like the message table.
For this scene 1, 2 tables are created with every registration.
Scene 2: Adding Rows
The scenario is same here as well, but in this case I have 2 tables for message and cart. Rows are added only when there is an activity.
Note:
You must assume that the number of users is more than 2000 and expect 50+ users to be active all the time. Which means the message and cart tables are always busy for both the cases. Like there is always a query for update, add, delete, insert, select etc. simultaneously.
Also which scene will consume more disk space.
While writing this, it make me wonder what technique would Facebook and others use. If they use the Scene 2 style (all users (billions) use the same big long message table)... Just wondering
Databases has some basic rules defined for Database Design called
"Database Normalization", These basic rules allow us eliminating
redundant data.
1st Normal Form
Store One piece of information in only One Column, A column should store only One piece of information.
2ns Normal Form
A Table should have only the columns that are related to each other. All the related columns should be in One table.
Now if you look at your advised design, A Separate Table for each USER
will split SAME information/Columns about all the user in 1000's of
tables. Which violates the 2nd Normal Form.
You need to Create One Table and put all the related Columns in that
one table for all the users. and you can make use of normal t-sql to
query your data but if you have a table for each user my guess is your
every query that you execute from your application will be built
dynamically and for every query you will be using dynamic sql. which
is one of the Sql Devils and you want to avoid using it whenever
possible.
My suggestion would be read more about Database Design. Once you have
some basic understanding of database design. Draw it on a piece of
paper and see if it provides you everything that your business
requires / expects from this application , Spend sometime on it now it
will save you a lot of pain later.

Orchard CMS: presenting 1:n tables data

I want to use orchard for a medium-sized company site.
The old site was written in pure ASP.NET 3.5 and had for example this database-tables:
Departement:
ID,
Description
Contact:
ID,
DepartementID,
Name,
Image
No problem to make a page, listing the departments, linking to another page, where the Contacts are presented in a list (html-table)
with an SQL like
SELECT Name, Image From Contact Inner Join Departemnt on Contact.DepartementID = Departemnt.ID...... or so...
How would I mimic this in Orchard?
Or even better... could I create these tables inside the Orchard-db (or an external db) and write a (classic) ASP.NET page that presents the data inside the Orchard-Website?
Would I need to create a Module for this (How?)
Would these tables be searchable from the Orchard-internal search? (indexed by Lucene?)
I also need to make a Create/Update/Delete-page for the tables.
...inside the Dashboard? (as they have to be protected/authorized access only)
Lastly... I do NOT want to have every single record show up as a Content-Item in Dashboard!!
I need one CRUD-page with traditional record-per-line, sort, pageing, update/delete like in a conventional Access-Form
Is this at all possible in Orchard??
Thank you,
Reinhard
Of course it's possible (read http://docs.orchardproject.net/Documentation/Creating-1-n-and-n-n-relations), but if you want the benefits of content types, such as searchability, just make it a content type. Content types won't necessarily appear in the list of items. They will only appear if they are marked creatable, so just don't mark your types as creatable and you should be good to go.

best practice to sync two different systems users table

I am having a main stream website and I would like to include Forum functionality. Since it is a java based system, I opt for Jforum. Now since the JForum having it's own login table and use it from there, I would like to make this to use mainstream login sysem. Can any one post me what are the best practice to do it? Duplicating the data in both the table? Create a view and refresh periodically? I am using MySQL database.
Copying the data from one table to another is not a good idea, as it can introduce inconsistencies in the data. The best solution is to create a View, as you mentioned. Simply add any columns that JForum needs to the main stream website database, and create a view that simulates the table name and column format that JForum is expecting. If done correctly, JForum should simply read from the VIEW which is nothing but a SQL query that changes your existing Users table to appear the way it's expecting it to.