I'm having a weird problem in my Stock module.
once in a while when I check my stock move
I'll get a stock_move without picking_id in the database,
this is the example of the data:
id |create_date |write_date |product_id |location_dest_id |location_id |picking_id |State
------ -------------------- -------------------- ----------- ----------------- ------------ ------------ ------
144661|2013-08-03 15:55:00 |2013-08-03 16:23:57 |88754 | 9 |341 |40194 |draft
144662|2013-08-03 16:20:41 |2013-08-03 16:21:43 |88749 | 9 |970 | |draft
144663|2013-08-03 16:20:41 |2013-08-03 16:21:43 |76879 | 9 |970 | |draft
144664|2013-08-03 16:29:08 | |88749 | 9 |970 |40194 |draft
144665|2013-08-03 16:29:08 | |76879 | 9 |970 |40194 |draft
Have any of you ever met this issue before?
can you tell me how can I trace the cause of this issue?
thx for your help
In OpenERP, the stock.move objects that have values for picking_id are only the stock.move objects that correspond directly to the stock.picking object. For example, each line on a delivery order is a stock.move object with the picking_id field referencing the delivery order (stock.picking.out).
However, there are often other stock.moves that are generated by an action. For instance, when using the mrp module to manufacture a product, a stock.move is generated from the manufacturing location to the default inventory location. This stock.move does not correspond to a picking, and will not have a picking_id, but it may be chained to a stock.move that does belong to a stock.picking.
It is possible to trace chained stock.move objects to their eventual stock.picking object by looking at the field move_dest_id. This field represents the stock.move object that is next in the chain. Looking at your data, I would expect the two moves that are missing picking_ids to correspond to the two moves below with the same product_ids.
Related
Much ink has been spilled on the topic of sum types in SQL. The standard solutions are called absorption, separation, and partition; see, e.g.: https://www.inf.unibz.it/~montali/teaching/1415/dpm/slides/4.relational-mapping.pdf .
I want to ask about how to encode open sums. Normal sums allow a field to be one of a fixed set of several different types; with open sums, this set is not fixed.
The basic setup in our program: There is a list of "triggers," where each trigger can be one of many different things. Plugins can be written defining new trigger types, although the set of trigger types can be assumed to be known at compile time.
We want a table of all triggers.
Our current best idea:
Dynamically create a materialized view of the following form:
id | id_in_plugin_table | thing_in_main_program_it_refs | plugin_name
---------------------------------------------------------------------
1 | 27 | 8 | RegexTrigger
2 | 27 | 12 | RidiculouslyUnsafeCustomJSTrigger
This relation is automatically generated from the various plugin tables, each of which have their own ID and a thing_in_main_program_it_refs field.
For illustration, here's what the referenced tables may look like.
RegexTrigger table:
id | thing_in_main_program_it_refs | regex
---------------------------------------------------------------------
27 | 8 | hel*o
RidiculouslyUnsafeCustomJSTrigger
id | thing_in_main_program_it_refs | custom_js
---------------------------------------------------------------------
27 | 12 | (x) => isPrime(x.length())
Either use two roundtrips to lookup the plugin table and then query it, or combine them into a single SQL program which uses EXEC.
I'm happy with part 1, but not with part 2. Neither option sounds efficient, and the latter option uses EXEC.
So, we're looking for either (a) a better way to dynamically select a table in a query, or (b) a different approach to open sums.
I'm designing the database model for the delivery application.
I have a DeliveryWeek entity that represents a single week and a DeliveryDay entity that represents a day of the week (Monday-Friday).
There is also a DeliveryWeekDay entity that joins DeliveryWeek and DeliveryDay in many-to-many relationship.
There is also DeliveryHour entity and DeliveryDayHour entity that joins DeliveryDay and DeliveryHour in many-to-many relationship.
For most of the weeks delivery hours are the same but, in some cases, (holiday week) they might be different.
I want to be able to modify default delivery hours for all new DeliveryWeeks but for some DeliveryWeeks these hours can be overwritten.
Should I use two separate tables? For example DefaultDeliveryHours for the default values and every time when I create a new DeliveryWeek I should make a new DeliveryHour entries based on DefaultDeliveryHour data?
I think there are two ways you could go:
First is without DeliveryWeekDay:
--------------- -------------
| DeliveryWeek| |DeliveryDay|
|-------------| |-----------|
|Year (PK) | |Id (PK) |
|Weeknr (PK) | |Weekday |
|MonId |---> |Properties |
|TueId |---> -------------
|WedId |--->
|ThuId |--->
|FriId |--->
---------------
Via the id you could define different DeliveryDays with different properties. Your code (program or sql trigger) should then make sure that MonId only references monday weekdays etc. for the other weekdays!
The second variant would be with a DeliveryWeekDay relation table - which looks like:
--------------- ----------------- -------------
| DeliveryWeek| |DeliveryWeekDay| |DeliveryDay|
|-------------| |---------------| |-----------|
|Year (PK) |<---|Year (PK/FK) |--->|Id (PK) |
|Weeknr (PK) | |Weeknr (PK(FK) | |Weekday |
--------------- |DDayId (PK/FK) | |Properties |
----------------- -------------
Here you also have to make sure that your code (program vs sql trigger) makes sure that for every DeliveryWeek there are 5 entries (for every weekday) within your DeliveryWeekDay table - except if there is a holiday within that week.
In both ways you could make DeliveryDay.Id = 1 the default and use other id values for your special cases.
The same concept goes for your DeliveryHour table. Please don't use an extra default table, because it is only a redundant one.
If I understand you correctly you are using the "DeliveryWeekDay" entity as reference.
You could design your "DeliveryWeekDay" like this:
ID,DeliveryWeekID,DeliveryDayID,DeliveryHoursID, DefaultDayID, DefaultHoursID.
So if "DeliveryDayID" is null you return "DefaultDayID" and if "DeliveryHoursID" is null you could return "DefaultHoursID". Assuming you query by SQL:
SELECT ID,DeliveryWeekID,ISNULL(DeliveryDayID,DefaultDayID),ISNULL(DeliveryHoursID,DefaultHoursID)
This way you can have default value but also change the default for some entries.
I am sure this question has been asked before, but I'm so new to SQL, I can't even combine the correct search terms to find an answer! So, apologies if this is a repetition.
The db I'm creating has to be created at run-time, then the data is entered after creation. Some fields will have a varying number of entries, but the number is unknown at creation time.
I'm struggling to come up with a db design to handle this variation.
As an (anonymised) example, please see below:
| salad_name | salad_type | salad_ingredients | salad_cost |
| apple | fruity | apple | cheap |
| unlikely | meaty | sausages, chorizo | expensive |
| normal | standard | leaves, cucumber, tomatoes | mid |
As you can see, the contents of "salad_ingredients" varies.
My thoughts were:
just enter a single, comma-separated string and separate at run-time. Seems hacky, and couldn't search by salad_ingredients!
have another table, for each salad, such as "apple_ingredients", which could have a varying number of rows for each ingredient. However, I can't do this, because I don't know the salad_name at creation time! :(
Have a separate salad_ingredients table, where each row is a salad_name, and there is an arbitrary number of ingredients fields, say 10, so you could have up to 10 ingredients. Again, seems slightly hacky, as I don't like to unused fields, and what happens if a super-complicated salad comes along?
Is there a solution that I've missed?
Thanks,
Dan
based on my experience the best solution is based on a normalized set of tables
table salads
id
salad_name
salad_type
salad_cost
.
table ingredients
id
name
and
table salad_ingredients
id
id_salad
id_ingredients
where id_salad is the corresponding if from salads
and id_ingredients is the corresponding if from ingredients
using proper join you can get (select) and filter (where) all the values you need
While trying to build a data warehousing application using Talend, we are faced with the following scenario.
We have two tables tables that look like
Table master
ID | CUST_NAME | CUST_EMAIL
------------------------------------
1 | FOO | FOO_BAR#EXAMPLE.COM
Events Table
ID | CUST_ID | EVENT_NAME | EVENT_DATE
---------------------------------------
1 | 1 | ACC_APPLIED | 2014-01-01
2 | 1 | ACC_OPENED | 2014-01-02
3 | 1 | ACC_CLOSED | 2014-01-02
There is a one-to-many relationship between master and the events table.Since, given a limited number of event names I proposing that we denormalize this structure into something that looks like
ID | CUST_NAME | CUST_EMAIL | ACC_APP_DATE_ID | ACC_OPEN_DATE_ID |ACC_CLOSE_DATE_ID
-----------------------------------------------------------------------------------------
1 | FOO | FOO_BAR#EXAMPLE.COM | 20140101 | 20140102 | 20140103
THE DATE_ID columns refer to entries inside the time dimension table.
First question : Is this a good idea ? What are the other alternatives to this scheme ?
Second question : How do I implement this using Talend Open Studio ? I figured out a way in which I moved the data for each event name into it's own temporary table along with cust_id using the tMap component and later linked them together using another tMap. Is there another way to do this in talend ?
To do this in Talend you'll need to first sort your data so that it is reliably in the order of applied, opened and closed for each account and then denormalize it to a single row with a single delimited field for the dates using the tDenormalizeRows component.
After this you'll want to use tExtractDelimitedFields to split the single dates field.
Yeah, this is a good idea, this is called a cumulative snapshot fact. http://www.kimballgroup.com/2012/05/design-tip-145-time-stamping-accumulating-snapshot-fact-tables/
Not sure how to do this in Talend (dont know the tool) but it would be quite easy to implement in SQL using a Case or Pivot statement
Regarding only your first question, it's certainly a good idea -- unless there is any possibility of the same persons applying-opening-closing their account more than once AND you want to keep all this information in their history (so UPDATE wouldn't help).
Snowflaking is definitely not a good option if you are going to design a data warehouse. So, denormalizing will certainly be a good choice in this case. Following article almost fits perfectly to clear the air over such scenarios,
http://www.kimballgroup.com/2008/09/design-tip-105-snowflakes-outriggers-and-bridges/
I'm building a database for archery tournament shoots.
One of the tables holds the work shifts for the volunteers working it.
It currently looks like this:
+-------+---------+--------+---------+-------+-----+
| JobID | ShiftID | UserID | EventID | Hours | Day |
+-------+---------+--------+---------+-------+-----+
| 10 | 9 | 1125 | 6 | NULL | 1 |
| 11 | 9 | 0 | 6 | NULL | 1 |
+-------+---------+--------+---------+-------+-----+
JobID links to the jobs i.e. registration, kitchen.
ShiftID links to the hours of the shift i.e. 7-9 (hours is there at the request of the event owner as a shift may run long).
UserID links to the volunteer...
EventID links to the specific event.
Day is day of the event, for events that span multiple days.
The entries are populated for the events, and then users are added.
This currently allows for a unique constraint to be placed on the concatenated columns (JobID, ShiftID, UserID, EventID).
However, the event owner now wants to be able to have multiple shifts in an event at the same time. The entries will be unique after the user has been registered.
What would be the proper way to deal with this?
These were the solutions that I thought of, but none of them felt right:
Making a new shift.
Making a new job.
Making a new table for pending jobshifts.
Removing the unique constraint on the table.
Adding another column to deal with the duplicate shifts.
Your concern is with the constraints.
One method of fitting the multiple shifts into the current schema is to "invent" place-holder users. If you only needed to support two shifts at the same time, you can just set the user to NULL and the constraint is ok. For more than two shifts, create new user ids -- perhaps with negative ids so they are obvious -- that really mean "there is no user for this shift yet".