I'm running SAP R/3.
The table E071 stores objects from transport requests. There is a 4 character field in it called OBJECT that stores the object type. Like PROG for program, TABD for table, etc.
I have an internal table with objects selected from E071.
The objects with type TABL can both be a normal structure and an append structure.
In SE11, when you view a structure object, if it's a normal structure, it shows a text that says Structure by the object name. And if it's an append structure, it shows Append Structure there.
So there is a way to differentiate them.
How should I go about differentiating them inside my program? Is there any technical detail that is different between these two?
ABAP DDIC structures are stored in the DD02L table, which stores also miscellaneous objects like tables and views, which have these important columns :
TABNAME : the object name
TABCLASS : the object class INTTAB for normal structure, APPEND for append structures, and other values for tables and views (including TRANSP for transparent tables)
SQLTAB : if the object is an append structure, it contains the object which it appends.
Related
I have the following data, (All the data will be TEXT).
The following data is for Language files for multi-language translation.
data: {
'MAIN_KEY':{
'A_UNIQUE_KEY':'data1',
'A_UNIQUE_KEY':'data2',
'A_UNIQUE_KEY':'data3',
},
'MAIN_KEY':{
'A_UNIQUE_KEY':'data1',
'A_UNIQUE_KEY':'data2',
'A_UNIQUE_KEY':'data3',
'A_UNIQUE_KEY':'data2',
'A_UNIQUE_KEY':'data3',
},
......
}
Here, the MAIN_KEY will be different for each set. In this case component name, Eg: LOGIN_PAGE
A_UNIQUE_KEY will also different in each case. In this case field name. Eg: USER_NAME and so on.
The number of Key-value pairs in each set will also be different.
I need to store the data for multiple languages. But the MAIN_KEY and A_UNIQUE_KEY will be the same for every file.
Every file will be of the same structure but only the data1, data2.. will be different,
What I want to achieve is that to store and manage the data in this format and later generate a JSON file through an API for my different applications. I should be able to do CRUD operations on this data.
Is creating a Database is the only option here?
XML and JSON are hierarchical structures like a tree, where a parent node can have child nodes and each child node has exactly one parent node, whereas a database is typically a relational system where an entity can have many parents, siblings and children so-to-say :-)
This means in order to store your JSON you have at least these three options:
Create a simple database in an RDBMS where each child table has just one parent table.
Have just one table in an RDBMS and store your JSON in a row in that table. (After all the JSON is just a string.)
Use a non-relational DBMS. There even exist JSON DBMS, if I'm not mistaken.
Which option you choose would depend on your data and what you want to do with it.
I ended up using DynamoDB.
With DynamoDB I can store the data in One Table using the Composite Key. And use DynamoDBMapper to do the CRUD operations.
TL;DR:
I want to use a non-relational design to store a tree of nodes in a self-referencing table because we will never need to relationally select subsets of data. This allows for extremely simple recursive storage and retrieval functions.
Coworker wants to use a relational design to store each specific field of the object -- I assume because he believes relational is simply always better. (he doesn't have any specific reasons) This would require more tables and more complex storage and retrieval functions, and I don't think it would serve to benefit us in any way.
Is there any specific benefits or pitfalls to either of the design methods?
How are trees normally stored in databases? Self referencing tables?
Are there any known samples of trees of data being stored in databases that might coincide with the task we are trying to solve?
At work we are using a complex structure to describe an object, unfortunately I cannot share the exact structure because of work restrictions but I will give an equivalent example of the structure and explain the features of it.
The structure can be represented in json but actually conforms to a much tighter syntax restriction.
There is four kinds of entities in the structure:
top level node
This node is a json object and it must be the top level json object
This node must contain exactly 4 attributes (meta info 1 through 4)
This node must contain exactly 1 'main' container node
container nodes
These are json objects that contain other containers and pattern nodes
Must contain exactly 1 attribute named 'container_attribute'
May contain any number of other containers and patterns
pattern nodes
These are json objects that contain exactly 3 attributes
A pattern is technically a container
May not contain anything else
attribute nodes
These are just json string objects
The top level container is always a json object that contains 4 attributes and exactly 1 container called 'main_container'
All containers must contain a single attribute called 'container_attribute'.
All patterns must contain exactly three attributes
An example of a structure in json looks like the following:
{
"top_level_node": {
"meta_info_1": "meta_info_keyword1",
"meta_info_2": "meta_info_keyword2",
"meta_info_3": "meta_info_keyword3",
"meta_info_4": "unique string of data",
"main_container": {
"container_attribute": "container_attribute_keyword",
"sub_container_1": {
"container_attribute": "container_attribute_keyword",
"pattern_1": {
"pattern_property_1": "pattern_property_1_keyword",
"pattern_property_2": "pattern_property_2_keyword",
"pattern_property_3": "unique string of data"
},
"pattern_2": {
"pattern_property_1": "pattern_property_1_keyword",
"pattern_property_2": "pattern_property_2_keyword",
"pattern_property_3": "unique string of data"
}
},
"pattern_3": {
"pattern_property_1": "pattern_property_1_keyword",
"pattern_property_2": "pattern_property_2_keyword",
"pattern_property_3": "unique string of data"
}
}
}
}
We want to store this structure in our internal office database and I am suggesting that we use three tables, one to store all json objects in a self-referencing table and one to store all json strings in a table that references the json object table, and then a third table to tie the top level containers to an object name.
The schema would look something like this:
Where an attibutes table would be used to store everything that is a json string with references to parent container id:
CREATE TABLE attributes (
id int DEFAULT nextval('attributes_id_seq'::text),
name varchar(255),
container_id int,
type int,
value_type int,
value varchar(255)
);
The containers table would be used to store all containers in a self-referencing table to create the 'tree' structure:
CREATE TABLE containers (
id int DEFAULT nextval('containers_id_seq'::text),
parent_container_id int
);
And then a single list of object names that point to the top level container id for the object:
CREATE TABLE object_names (
id int DEFAULT nextval('object_names_id_seq'::text),
name varchar(255),
container_id int
);
The nice thing about the above structure is it makes for a really simple recursive function to iterate the tree and store attributes and containers.
The downside is it's not relational whatsoever and therefore doesn't help to perform complex relational queries to retrieve sets of information.
The reason I say we should use this is because we have absolutely no reason to select pieces of these objects in a relational manner, the data on each object is only useful in the context of that object and we do not have any situations where we will need to select this data for any reason except rebuilding the object.
However my coworker is saying that we should be using a relational database design to store this, and that each of the 'keyword' attributes should have it's own table (container keyword table, 3 pattern keyword tables, 4 top level keyword tables).
The result is storing these objects in the suggested relational design becomes significantly more complex and requires many more tables.
Note that query speed/efficiency is not an issue because this object/database is for internal use for purposes that are not time-sensitive at all. Ultimately all we are doing with this is creating new 'objects' and storing them and then later querying the database to rebuild all objects.
If there is no benefit to a relational database design then is there any reason to use it over something that allows for such a simple storage/retrieval API?
Is there any significant issues with my suggested schema?
"we will never need to X" is a rather bold assumption that turns out to be unwarranted more often than you might suspect. And in fact with tree structures in particular, it is most natural for the requirement to arise to "zoom into a node" and treat that as a tree in its own right for a short time.
EDIT
And in case it wasn't clear why that matters : relational aproaches tend to offer more flexibility because such flexibility is built into the data structure. Non-relational approaches (typically implying that everything is solved in code) tend to lead to additional rounds of codeshitting once requirements start to evolve.
It’s not very clear how idProperty is used in the data store when building a data model. The documentation says “If the store has a single primary key, this indicates the property to use as the identity property. The values of this property should be unique. This defaults to "id".
Is this assuming the schema from which the model is based, has a mostly flat structure? For example an array of objects – each with an identity property?
What if the schema is not a simple array but has more complex structure starting from a single object that contains several sub levels of properties within properties. OR is just multiple arrays on the same level where each group of arrays identify property are independent of one another?
A store is an extension of a collection.
A collection is the interface for a collection of items (your obect with a potentially complex schema).
You can use Custom Querying on a collection to define special queries to find your data with any subset of properties.
In short, yes you can querying your data even if it has a custom schema but you need to define a Custom Querying.
More info can be found here at the end of the article: https://github.com/SitePen/dstore/blob/master/docs/Collection.md
I am new to ABAP if anyone can tell me a website which I can refer to learn ABAP in depth or to understand it better, I have confusions with this global structures, internal tables, and work areas, someone please explain the need of them clearly with difference in each.
thanks in advance.
Internal tables are a bit like lists in other languages, for instance like a List< T > in c#. They exist only in memory and only within the program they were defined in. I never encountered the term "global structure" as such, but structures are pretty much the same as in other languages. In abap they can be used to define the row structure of tables. Translate this to c# and you would end up with a class X with some properties (your row structure) and a List< X >, your internal table.
Work areas are essentially a single row of a defined structure. Work areas are for instance used to hold the contents of a single row when looping over an internal table. For instance:
data:
it_vbak type standard table of vbak,
wa_vbak type vbak.
select * from vbak into corresponding fields of table it_vbak.
loop at it_vbak into wa_vbak.
....
endloop.
this defines both an internal table it_vbak and a work area wa_vbak. Both are defined using the structure of the DDIC table VBAK, that is one of the SAP ERP tables and contains sales order header data. The example selects some data (in this case: all of it, not a good idea) into the internal table and then loops over the entries in the internal table. At the beginning of each loop, the contents of the current row are transferred to the work area. You can for instance manipulate the contents within the loop and then move the modifications back into the table by using the abap command modify:
modify it_vbak from wa_vbak.
You can define structures both within a program (using the TYPES keyword) and in the SAP ERP Data Dictionary (DDIC). The DDIC is globally available to all programs and contains definitions for tables, structures, views, table definitions, data elements and domains (and a bunch of stuff more which isn't too relevant here).
as a general reference for abap have a look at the SAP Help portal
Is there to code a superclass in sql oracle or would you code it as a normal class?
this is a part of my er diagram of my super class:
*Sorry, I'm a beginner with sql
There exist several different approaches for this:
store all data in a single table (this table has columns for all parent and child attributes)
use one table per leaf class, store all attributes in this table (no common table)
use one table per class, store only class-specific attributes in this table (use a common table for the base class data, and add FK references to this table in your detail tables)
I'd recommend you grab a copy of Patterns of Enterprise Architecture - it contains exhaustive information on how to handle situations like this.