I need to load data into a parent-child pair of tables with SQL Loader.
For various reasons the customer prefers to extract the data into one consolidated file, hence I'll have a data file containing main records (ID, First Name and Last Name) and then several phone numbers for each main record (ID, phone type, phone).
1, John, Doe
2, Mary, Doe
3, Sandy, Smith
1, home, 88899999
1, mobile, 7777777
2, home 6666666
3, office,3333333
3, mobile, 7777777
My goal is to load two tables: emp - with main record data and emp_phones with child records.
Is it possible to implement this with SQL Loader?
I can request from them to put some record "type" identifier in front of the line, like 'main', or 'phone' if it helps.
I would say that some sort of type indicator not just helps, but is required. SQL Loader has a "when" clause that will allow you to decide which table to load your records into.
Related
I have to reference information of a table using the PK from another table. For that I have to see if the information matches in a third table.
To better explain, I show you the screenshots the SELECT from the tables I need to use or change.
In the next two screenshot of tables, I have an Address table that contains information about differentes addresses and an "addressid" PK. The next table, is a Company table that provides information about differentes companies. These companies need to have two FKs to the Address table in the two different columns that are empty.
So, I have a table with a lot of mixed information, including the addresses combined with the companies.
Using this "import" tables, I have to set the empty FK on Company table related to the PKs of Address table.
I have tried doing an UPDATE function but I don't really know how to write the conditions to use this "import" table to relate the other two tables.
Thanks on advance.
In the IMPORT table I have all the info in Company table and Address table, but mixed, with other unused information. So, I have for each row in Company, look at the Company name, search it on the import table, look in the same row what is the address, search it on the Address table and put the correspondent PK on the Company table... Example: COMPANY - Google IMPORT - Google California ADDRESS - Californa id1 Go to COMPANY - Google (add id1 on column address)... Sorry if I explain it not so good.
Something like this might work for the shipping address:
update company c
set ordership_address = (select addressid
from address a
inner join import i
on a.addressname = i.ordershipadress
and a.postalcode = i.ordershippostalcode
-- and other criteria ?
where i.companyname = c.companyname)
Don't know how your address.cityid maps to something so leave that one for you.
I have a set of 100 “student records”, I want to have checkboxes for each "favorite_food_type" and "favorite_food", whichever is checked would filter a "bar graph" that counts number of reports that contain that specific "favorite_food"type" and "favorite_food" schema could be:
name
favorite_food_type (e.g. vegetable)
favorite_food (e.g. banana)
I would like to in the dashboard be able to select via checkboxes, “Give me all the COUNT OF DISTINCT students with favorite_food of banana, apple, pear“ and filter graphs for all records. My issue is for a single student record, maybe one student likes both banana and apple. How do I best capture that? Should I have:
CASE A: Duplicate Records (this captures the two different “favorite_food”, but now I have to figure out how many students there are (which is one student)
NAME, FAVORITE_FOOD_TYPE,FRUIT
Charlie, Fruit, Apple
Charlie, Fruit, Pear
CASE B: Single Records (this captures the two different “favorite_food”, but is there a way to pick out from delimiters?)
NAME, FAVORITE_FOOD_TYPE,FRUITS
Charlie, Fruit, Apple#Pear
CASE C: Column for Each Fruit (this captures one record per student, but need a loooot of columns for each fruit, many would be false)
NAME, FAVORITE_FOOD_TYPE, APPLE, BANANA, PINEAPPLE, PEAR
Charlie, Fruit, TRUE, FALSE, TRUE, FALSE
I want to do this as easy as possible.
Avoid Case B if at all possible. Repeating information is almost always best handled by repeating rows -- not by cramming multiple values into a single table cell, nor by creating multiple columns such as Favorite_1 and Favorite_2
If you are provided data with multiple values in a field, Tableau does have functions and data connection features that can be used to split a single field into its constituent parts to form multiple fields. That works well with fixed number of different kinds of information -- say splitting a City, State field into separate fields for City and State.
Avoid Case C if at all possible. That cross tab structure makes it hard to analyze the data and make useful visualizations. Each value is treated as a separated field.
If you are provided data in crosstab format, Tableau allows you to pivot the data in the data connection pane to reshape into a form with fewer columns and many rows.
Case A is usually the best approach. You can simplify it further by factoring out repeating information into separated tables -- a process known as normalization. Then you can use a join to recombine the tables and see the repeating information when desired.
A normalized approach to your example would have two tables (or tabs in excel). The first table would have exactly one row per student with 2 columns: name and favorite_food_type. The second table would have a row per student/favorite food combination, with 2 columns: name and favorite_food. Now each student can have as many favorite foods as you like or none at all. Since both columns have a name field, that would be the key used to join (combine) the tables when needed.
Given that table design, you could have 2 data sources in Tableau. The first one just pointed to the student table and could be used to create visualizations that only involved students and favorite_food_types. The second data source would use a (left) join to read from both tables and could be used to look at favorite foods. When working with the second data source, you would have to be careful about reporting information about student names and favorite food types to account for the duplicate information. So use the first data source when possible. Finally, you could put both kinds of visualizations on a dashboard and use filter and highlight actions to make interaction seamless despite the two sources -- getting the best of both worlds.
I'm creating a database for a small magazine in Filemaker Pro 14. Each subscriber can have multiple subscription records, so in the 'Subscriber' layout, I have inserted a portal which shows the list of related subscription records for the subscriber I'm viewing.
When I run a Find operation to view only current subscribers and then export this as a CSV (adding the subscription start and end date as an exported field), I get a list of all current subscribers, but also all the subscription records for each one. I want to limit this so that I only get the current, active subscription record for each subscriber. It looks like this:
ID, firstname, lastname, address, city, state, zip, begin_issue, end_issue
1, John, Doe, 123 Anystreet, Anytown, ST, ZIP, 32.4, 33.3
, , , , , , , 33.4, 34.3
, , , , , , , 34.4, 35.3
I just want to get:
ID, firstname, lastname, address, city, state, zip, begin_issue, end_issue
1, John, Doe, 123 Anystreet, Anytown, ST, ZIP, 34.4, 35.3
I have created a layout with a portal that includes a filter which only returns the active subscription. However when I export from this layout, I get exactly the same result - it includes all related records.
Thanks for any thoughts on this.
I want to limit this so that I only get the current, active
subscription record for each subscriber.
Exports work at the data layer, so it doesn't matter what you have on the layout. You can have a filtered portal, or no portal at all; still, when you include a related field in the export field order, data from all related records will be exported.
To export all (and only) current subscriptions, do your export from the Subscriptions table, after finding only current subscriptions, and include the necessary fields from the Subscribers table.
Simply duplicate this layout, move the fields from the related table directly onto the layout itself, then delete the layout. Only fields from the first related record will be exported. (If you don't get the related record you want, you'll need to adjust the sort order of the relationship you're using).
I'm trying to plan a NOSQL table schema. There are relationships in my data, but they are mostly what would be N:N in a relational db; there are very few normal 1:N relationships.
So in this case, I'm trying to create implicit relationships that will allow me to browse from both ends of the relationship. I'm using Azure Table Storage, so I understand that full-text searching isn't available; I can only retrieve an "object" by its Partition Key + Row Key combination.
So imagine I have a table called "People" and a table called "Hamburgers" and each object in the tables can be related to multiple objects in the other table. Hamburgers are eaten by many people, people each eat many hamburgers.
Since the relationship is probably weighted to the people side - i.e. there are more people per hamburger than vice-versa, I would handle this in the tables like this:
Hamburger Table
Partition Key: Only 1 partition
Row Key: Unique ID
People Table
Partition Key: Only 1 partition
Row Key: Unique ID
"Columns": an extra value for every hamburger the person eats
Hamburger-People Table
Partition Key: Hamburger Row Key
Row Key: People Row Key
This way, if I'm looking at a hamburger and want to see all the people that eat it, I can go to the Hamburger-People table and use my Hamburger's Row Key to get the partition of all the people that eat the hamburger.
If I'm at a person and want to see all the hamburgers he/she eats, I have the extra values with the Row Keys of the hamburgers the person eats.
When inserting data into the tables, if the data involves a hamburger/person relationship, I would insert both values in the proper tables, then create the Hamburger-People table. If I was trying to keep a duplicate-free list of hamburgers, I would need to search the Hamburger table first to make sure the hamburger wasn't already in there (like "Whopper" - if it's in there, I wouldn't insert it again). Then, I would need to go insert a row in the hamburger's existing partition in Hamburger-People table.
But for the most part, the no-duplicate requirement doesn't exist.
Is this a good best-practices approach to NOSQL schema, or am I going to run into problems later?
UPDATE
Also, I would like to be able to partition the data tables later, but I'm not sure how to do so with this structure; adding a 2nd partition to the hamburger table would require me to store an extra value in the hamburger-People table, and I'm not sure if that would start to be too complex.
Ok, nice questions and I think most of them are the ones each RDMBS developer face as soon as hits NoSQL world:
1. How to group the partitions?
To get the best of the partitions you need to think that the load of your database should be distributed across your servers, lets see what will happend with your approach
A person with Key "A" enters to the restaurant you will save it and his burger, which is a Classic Tasty (Key "T") the person record goes to the server X and the Burger goes to server Y, now a new customer goes enters with the Key "B", and wants something different, a burger "W", again the person goes to server X and the burguer to server X, this time the server X is getting all the load, if you repeat this you'll see that the server X becomes a bottle neck, because 75% of the records are going there (all the people and 50% of the burgers), that will create some problems with your load. But... the problem will be better when you try to query because all the queries will hit the server X.
To solve this you could use the key of the person as part of the partition for the relationship, so the person will be partitioned in the same server of the burguers relationship, this way your workload will be balanced and you wont have any problems if one of the servers goes down (the person and hamburguers will be "lost" together), this will be a consistence "inconsistency"
2. Should I use a "relationship" in a NoSQL database?
Remember that NoSQL means that you are granted to duplicate information anytime your problem requires a solution to avoid "overqueries", so, if you can store the information that will be commonly queried together you will avoid a roundtrip to the database. So, if you store a "transaction" instead of "person and burguers" you will get a better performance and avoid some hits to the database, lets do an example of real data with your approach and compare it with "my" approach:
Joe Black comes to the restaurant and ask for a tasty, here you will do the following transactions:
Create a Joe Black record
Create a Burguer transaction record
if you want to list your daily transactions you will need to:
Get all the records from the day in the "table" person-burguer, then go to the person "table" and retrieve the name of the customers and now, go to the hamburguer records and retrieve their names. (you wont be able to do cross-table queries because some records could be in one server and others in the second server)
Ok, what if you create a table "transactions" and store in there the following json:
{ custid: "AAABCCC",
name: "Joe", lastName: "Black",
date: "2012/07/07",
order: {
code: "Burger0001",
name: "Tasty",
price: 3.5
}
}
I know you will have several records with the same "tasty" description, that's desnormalization which is very useful when you approach NoSQL solutions to these type of problems, now, how many transactions did you create to store the information to the database? just one! wow... and how many queries will you need to retrieve the information at the end of the day? again... just one, it will create some problems, but will save you a lot of work too, like... could you reprint the order easily? (yes you can!) what if the name of the customer changes? is that even possible?
I hope this help you some way,
I'm the creator of http://djondb.com so I think that having inside knowledge gives me a different approach to the problems according to what the database will be able to do, but I'm not aware of how azure will handle the queries if you are not able to query the document values and just the row keys, but anyway I hope this gives you an insight.
In Filemaker11.
I have a table, with a field categoryID, and want to Perform Find on these records.
I want to display only the records which have categoryID as either 1, 2, 4, 6, 12 or 13.
Perform Find doesn't seem to allow me to set up ORs... or at least I can't see where it does.
How can I do this?
Note: This table is actually connecting (with read-only permissions) to a table from a MySQL database, so I cannot set up a field which displays the boolean isOneOrTwoOr...
While in find mode, go to the 'Record' menu and select new find request. All find requests are ORed together. You can do the same thing in a script by doing the 'new record/request' script step.
you can do something like this (Assuming you using MySql database as you haven't mentioned)
Select * from tablename where categoryID in (1,2,4,6,12,13);
That's simple MySql query