i would like to know how you differentiate the different layer of description of a data field in a table
Example 1 :
a field is a varchar 255
the data in the varchar 255 is the code of a product, but it s the short code, not the long code
the product encoded is a food product
Example 2:
a char(3) contains a code iso country (FRA, USA,..) and the coutry is a coitry of production of a product,
Example 3 : float -> Amount -> Turnover
I guess that char(3) is called a "physical data type" ?
and the country of origin of a product is called "business term" and how is called the ISO codification ?
Related
I have imported my GA4 data into Google Data Studio and am trying to see how many giftcards have been sold by their value.
The item revenue metric in GA4 is equal to the giftcard value (i.e. revenue = $200 therefore $200 giftcard was sold).
I want to breakdown sales by giftcard value like so:
Giftcard (revenue)
Count
$200
4
$250
3
$300
6
To do this, I need to set a copy of item revenue as a dimension rather than a metric.
In Google Data Studio, I can create a calculated field with the following formula that should convert the item revenue into text:
CAST(Item Revenue AS TEXT)
The problem I'm having is that while the formula sets the field type as text, it is still regarded by GDS as a metric and can't be used as a dimension.
Even when I try to add text, GDS still recognises the field as a number:
CONCAT(CAST(Item Revenue AS TEXT), " giftcard")
To use a metric as a dimension you can make a combination of data. When defining the graphic element (table, for example) and the respective data source, just create a data combination, but do not combine the data with any other source and just define the combination with the initial data itself. So you will have the same data structure only through a combined structure.
When making a combination of data, data studio recognizes all calculated fields (metrics) as dimensions. Thus, it is possible to make the conversion.
I want to know the best database design for storing multi-currency money values in database.
For example I have one Entity that has two money fields. These fields may have different currency types for each record.
Example:
Table A:
-------------
Id
Name
Amount1
Amount2
Sample records:
Id Name Amount1 Amount2
1 aaa 12$ 15£
2 bbb 30€ 17$
I cannot store values in one currency. For example I want to lend somebody money. I store its data in a table. The type of money can be different. When I lend someone 10€ I should take back 10€ and I cannot store all values in one currency like dollar.
I want to know what the best and more efficient design for storing these values in database is.
Should I store amount and currency sign in one column with string data type or it is better to define Money and Currency tables as separate tables for storing money values?
Or any other design?
Without commenting too much on the actual structure of your table (2 or more monies in a single table is OK, as long as they have business meaning—like subtotal, shippingFee and total), I'll focus on how to store them:
Storing the monies
You should store the amount in one column, and the currency code in another.
Currency
You'll typically deal with ISO 4217, which comes with 2 codes for each currency:
a 3-letter alpha code, such as EUR or USD
a 3-digit numeric code, such as 978 or 840
Which one you use is up to you. You can save one byte per record by using numeric codes. On the other hand, alpha codes are easier to read and remember for humans, and could make it easier to use custom currencies (crypto), that may have a de-facto standard alpha code but no numeric code.
Amount
Because currencies may have different numbers of decimal places (2 for EUR, USD etc., but 0 for JPY, 3 for TND...), I always advise to store amounts in minor currency units (cents) as an integer.
Your table would therefore look like:
amount INT NOT NULL,
currencyCode CHAR(3) NOT NULL
If you want to store 12.34 USD, you'll actually store (1234, 'USD').
Multiple amounts, single currency
If your table holds several monies that will always be in a single currency (like the subtotal/shippingFee/total example above), all 3 amounts can share a single currency code:
subtotal INT NOT NULL,
shippingFee INT NOT NULL,
total INT NOT NULL,
currencyCode CHAR(3) NOT NULL
In this case, you probably don't need separate subtotalCurrencyCode, shippingFeeCurrencyCode and totalCurrencyCode, although there are other business cases where amounts will be in different currencies. The decision is yours.
Retrieving the monies
Of course dealing with integer amounts is not very easy, so you'll need to use a money library that supports converting from/to minor amounts.
For example in PHP, you can use brick/money (disclaimer: I'm the author):
$money = Money::ofMinor(1234, 'USD');
$money->getAmount(); // 12.34
$money->getMinorAmount(); // 1234
Never ever store multiple values in the same column!!
The currecny and the amount need to be separated. Also, if you have column names with numbers then you most probably do something wrong. This is one way to do it:
table products
--------------
id
name
table prices
------------
id
product_id
amount
currency_id
table currencies
----------------
id
name
abbreviation_sign
Then to get the Dollar price of a product you can do
select pri.amount
from prices pri
join products prod on prod.id = pri.product_id
join currencies c on c.id = pri.currency_id
where prod.id = 123
and c.name = 'Dollar'
With proper indexes this is really fast to query.
So from what I've understand the best example of differences in (Dimension, Dimension Attribute, and Fact) would be something like this:
Dimensions - PRODUCT, ACCOUNT, CUSTOMER
Dimension attribute - ProductName, ProductNumber, CustomerName, CustomerNumber
Facts - usually measures. Dollar, Unit, Height
This is my attempt so it may be wrong. I want to hear your solutions?
A dimension is a collection of "reference information" about a measurable event. The Measurable event is a Fact.
So, if you have data say for example - Retail transactions, you would measure - transaction cost. So, your fact will have sales amount. Now, sales amount in itself does not make sense. You would need information like -
When was the sale done - Date dimension
Who made the transaction - Customer dimension
Which store was it made from - Store Dimension
What was brought - Product dimension
and so on. What information you want capture for each dimension is called the attributes. For Ex: A Customer dimension might have these attributes -
Customer Number
Customer Name
Customer Address
Customer Zip Code
Date Of birth
... and so on.
Dimensions: are qualitative data. These are objects of the subjects.
Dimension attributes : These are columns of dimension table.
Facts : are the quantitative data. The data which can be summed up , averaged or manipulated. If manipulation is done in the data then it would be to provide business insights. Manipulated data eg : time dimension can't be measured but hours calculated using time is a measurable fact.
Example : Consider e commerce company table(amazon) which is Subject
Dimensions:
Product , date , customer , vendor , location(** these all are Objects of subjects**)
Dimension attributes:
PRODUCT - (Product_id , Product_name , Product_class)
DATE - (Order_date , Shipment_Date , Delivery_date)
CUSTOMER - (Cust_id , Cust_name)
LOCATION -(State , city , town , zip_code)
Facts:
PRODUCT - Total number of products sold
DATE - Total number of products sold in last one month/ last one year / last one quater
CUSTOMER - Total amount paid by customer
LOCATION - Total sales done per region , per state , per city
- Total traffic(customer visited) in stores per region
I have a set of 3 parameters each can take 3 values
eg.
paramerets value1 value2 value2
country india US UAE
language hindi english urdu
currency Rs Dollar Dinar
based on above i have saved records like
Name country language currency
A india hindi Rs
B US hindi dollar
C UAE english Rs.
D india english Rs.
Plus i have a few filters declared as follows:
Filtername country language currency
Dont_care_filter Any Any Any
A_Bit_Stringent_filter India,UAE hindi,english Rs.
Unique_filter India hindi Rs.
Now I need an algorithm to find the perticular filter a record belongs to?
( I case a record belongs to more than one filters it should be related to the more stringent filters ie having fewer number of values for each parameter )
what I have thought till now is represent these values of different params in form of ascii codes.
And what i need...
Is a hashing algorithm that can map one to many values ? i.e. I feed param values of one record, it matches with the precalculated hashes of all the filters declared and gives me the filer which contains the param values of the record.
I have to add a coupon table to my db. There are 3 types of coupons : percentage, amount or 2 for 1.
So far I've come up with a coupon table that contains these 3 fields. If there's a percentage value not set to null then it's this kind of coupon.
I feel it's not the proper way to do it. Should I create a CouponType table and how would you see it? Where would you store these values?
Any help or cue appreciated!
Thanks,
Teebot
You're correct, I think a CouponType table would be fit for your problem.
Two tables: Coupons and CouponTypes. Store the CouponTypeId inside the Coupons table.
So for an example, you'll have a Coupon record called "50% off", if would reference the percent off CouponType record and from there you could determine the logic to take 50% off the cost of the item.
So now you can create unlimited coupons, if it's a dollar amount coupon type it will take the "amount" column and treat it as a dollar amount. If it's a percent off it will treat it as a percentage and if it's an "x for 1" deal, it will treat the value as x.
- Table Coupons
- ID
- name
- coupon_type_id # (or whatever fits your style guidelines)
- amount # Example: 10.00 (treated as $10 off for amount type, treated as
# 10% for percent type or 10 for 1 with the final type)
- expiration_date
- Table CouponTypes
- ID
- type # (amount, percent, <whatever you decided to call the 2 for 1> :))
In the future you might have much more different coupon types. You could also have different business logic associated with them - you never know. It's always useful to do the things right in this case, so yes, definitely, create a coupon type field and an associated dictionary table to go with it.
I would definitely create a CouponType lookup table. That way you avoid all the NULL's and allow for more coupon types in the future.
Coupon
coupon_id INT
name VARCHAR
coupon_type_id INT <- Foreign Key
CouponType
coupon_type_id INT
type_description VARCHAR
...
Or I suppose you could have a coupon type column in your coupon table CHAR(1)