I need to create table where first column is names of clients and next ones are months of previous year starting from current month with amount of orders of user in this month. So my problem is that I don't really know how to name columns as months starting from current. I know that i can get name of month with namemonth() but i can't use it as name of column. Any ideas?
If I understand it right you want to dynamically name your columns. If you really want to do that you can write a script for that in your favorite programming language. But I don't recommend that you do that as it's not a good practive.
This is what I would do:
Create a table with 3 columns, the first one is the name or id of the client (of type int or varchar), the second one the date (of type date) and the third one the value (of type int as an amount of orders can only be a whole number). Then you can write a script to get the amount of orders for a specific (or all) client(s) with a script based on the date.
But if you really want to do what you said, which I really advise against, have a look at the link provieded by Progman in his comment.
Related
I've trouble understanding how this should work...basically I've 2 main tables, in one I've Revenues, in another Costs.
Revenues table has fields as: P&L (string), Category (string), Products (string), Sold (int), invoiced (int), delivered (int), date (date).
Costs table has: P&L (string), Category (string), Products (string), Costs (int), date (date).
I'd like to use tables together to perform various calcs like margin, for example, at any level (total margin, which means total revenues - total costs, or at Category level for which I should be able to filter any category I have and perform the calc and so on).
Problem is, any tentative I've made to use relations or join, resulted in duplications.
The only workaround I was able to perform so far is to leave revenues table as it is, and create many Costs table, 1 for field basically (table1 with category and costs plus date, table2 with products, costs and date etc.). Joining Revenues with one of these tables seems to work but, in this way, I'm not able to create a wider view (one goal is to make a big table in the viz where we could read at once all the data). Plus, another problem I 've seen it appear doing this workaround is that, if I want to split by date costs, but I use the date column from the revenues table, even if the date is the same (I've done a copy/paste between tables basically), tableau doesn't recognize the date correctly, so to split costs, I've to use costs'date column, and to split revenues, I've to use revenues' date columns, which is frankly a pain...
So my question: how could I merge the 2 tables in one, or anyway how could I put all the data together in a working table to perform any kind of calcs,and also how could I use just 1 column for date that works for all the date altogether?
I've upload a file here to understand better what I'm trying to combine. Thank you guys
Data file
ps.: seems that tableau is using sql behind for these tasks so probably someone skilled in this kind of problem in sql could also help...for this I 've tagged sql as well, thanks
You need to UNION those 2 tables together, but are they really in Google or you just did that to demo it here?
If you're using Excel - both Revenue & Cost must be different sheets in the same XLS file
If you're using CSV - both Revenue & Cost must be different files (hopefully in the same folder)
I would really hope that you're using a database (some form of SQL), but either of the above options, UNION the data and it will work the way you expect :)
I am trying to figure out how I should go about building my database structure (tables) for user information on my website. The kinds of information that I will be storing (at this time anyways) are:
About Me
Birthday (January, 1, 1970)
Sex (Male/Female)
Interested In: (Male, Female, Both)
Relationship Status: (Single, In a Relationship, Engaged, Married)
Website: (mywebsite.com)
From: (Cupertino, California)
So this is the type of information I will be storing for now. My question basically is, should I have this be one table only? Or would it be better to split the information up depending on what it was (my users have a unique ID which would go along with each table of information, obviously). So I'm not sure if I should have a table exclusively for Birthdays with the columns: userID, Month, Day, Year; or what.
If a user only needs to store one piece of information for an attribute, then you don't need a separate table for it. For example, a user only has one birthday. The only reason you would need a separate Birthdays table would be if you want to store multiple birthdays for the same userid. Each one of the attributes you've listed look like they'd be fine in one Users table.
As for splitting up Birthdays into the columns: userID, Month, Day, Year, it all depends on how you're going to use that information. Will you ever need to know just the Month, Day, or Year that a user's birthday falls on? If that's a common need, you might want to store them separately. It's usually not, so you probably just want to store it as a single Date value.
Note: You can take a look at the schema used by Stack Overflow by checking out the Data Explorer. They keep a similar collection of data in one Users table.
In the vast majority of cases, I've seen what you're asking being stored in one table - usually user or users.
Perhaps including a number of other elements too:
user id (unique)
registration date
status (live/expired/banned)
user hash
plus a variety of others...
Honestly - It's dependent on what you're building and how it's built, but my advice would be to start simple.
On your point about birthdays, just store the date in mysql date format:
YYYY-MM-DD
That way, you can manipulate it in a variety of ways using mysql functions.
Hope this helps.
I would like to let user see the date about the course. For example, a computer course will held on
1/9, 2/9, 3/9.
So, how to store these day in the database?
one column the store a string like this:
1/9/2011,2/9/2011,3/9/2011
or a separate table like this:
event_id date
1 1/9/2011
1 2/9/2011
1 3/9/2011
Thank you.
The separate table is the right design, because that's how your schema will be normalized. A table column should hold a single type of value.
First normal form of database normalization states:
Every row-and-column intersection contains exactly one value from the
applicable domain (and nothing else).
Almost every database under the sun has a DATE datatype, which will do exactly this.
Also: use data normalisation: The separate table is the way to go.
I would have a table with (at least) 3 columns, using the date type for the start and end date
event_id start_date end_date
1 1/9/2011 3/9/2011
A column should store exactly one value only. Separate table.
As a CSV, how can you
find course starting 2/9/2001
order by
delete 2/9/2001, add 4/9/2011 etc
both methods has it own benefits
first method will suit for simple data structure,
that's mean your data size could be small,
your project job scope is small,
and you don't wish to spent too many effort on that
the bad is hard to maintain in long run
second method will better for normalization
but require more code / JOIN to get the same piece of information
(you can do in one step in the first method)
Is BAD for date string in d/m/Y,
let the presentation language to determine the locale
ISO format YYYY-MM-DD will be the better choice
I have a large data set which I know contains many dupicate records. Basically I have data on first name, last name, different address components and date of birth.
I think the best way to do this is to use the name and date of birth as chances are if these things match, it's the same person. There are probably lots of instances where there are slight differences in spelling (like typos missing a single letter) or use of name (ie: some might have a middle initial in first name column) which would be good to account for, but I'm not sure how to approach this.
Are there any tools or articles on going about this process? The data is all in a MySQL database and I have a basic proficiency in SQL.
You could get a sense of how much dedupe you have to do by something like:
select birthDate,last_name,soundex(first_name),count(*)
from table
group by birthDate,last_name,soundex(first_name)
having count(*) >1
This will list the people with the same birthdate, last_name, and similar first names. Soundex() isn't great, but this could help you get a sense of amount of deduping.
This query below would allow you get the alphabetical first first_name from the table of similar named people. Hopefully this will give you some rough starting ideas//
select birthDate,last_name,soundex(first_name),min(first_name)
from table
group by birthDate,last_name,soundex(first_name)
having count(*) >1
With the second query, you could remove all occurrences of additional names, by using a DELETE where name not in, but that assumes you are willing to keep the lowest first_name and remove the rest...
Is there any benefit to storing Days of weeks, Months, Week number, user age, etc as Lookups vs plain text entry into the database? I am creating a social website with some analytic and planning to use a Question table, Answer table and Question_Answer table to store all the data like Gender, Birth months, Age, etc so I can give each an ID to use throughout the system but some older projects I worked on people always stored these are normal text entry only. So I am seeing which design is better to go with to store all the system and user fixed list data which may or may not be used later for reporting using various metrics. If using lookus then how deep to go, do i need to create days of weeks, days of year, weeks of month, etc if I want to create a report like: Comparing number of photos shared on the first of every month for a given set of users vs last day or every month for the same users?
Given that you are using MySQL, I suggest populating a date helper table, as suggested in the top-rated answer to this question: How to fill date gaps in MySQL?
The question itself should explain why you would want this table.