For example, how to translate some given from xml in GT.M saving order of following:
<Order>
<Item ID="6" Q="2"/>
<Item ID="5" Q="7"/>
<Item ID="8" Q="1"/>
</Order>
Perhaps, so:
g("Order","Item/0","ID")="6";
g("Order","Item/0","Q")="2";
g("Order","Item/1","ID")="5";
g("Order","Item/1","Q")="7";
g("Order","Item/2","ID")="8";
g("Order","Item/2","Q")="1";
But after removing first "Item" we must reorganize data. The data must be such:
g("Order","Item/0","ID")="5";
g("Order","Item/0","Q")="7";
g("Order","Item/1","ID")="8";
g("Order","Item/1","Q")="1";
It isn't effectively :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Temirhodzhaev, the design of your global is the problem. M databases use a hierarchical topography, rather than the flat tables of a relational database. While this is different, it is not necessarily bad - many problems are in fact hierarchical in nature and work better if laid out that way, rather than in tables. Generally, this go better when you apply the same normalization rules that you would use with a relational system.
Would be on possible representation of the XML input. This is close to what you originally proposed (at least in many ways). It organizes the data by the arriving XML, effectively by Item ID.
If the position or line number is important, then something like (say) this would serve:
This representation and your original one both add an implicit quantity for line number, which is not in the XML input.
Actually, M implicitly addresses the issue of the data organization because the delete (KILL) is a hierarchical operation - deleting a line (or an item id) in your original proposal and the other suggestions, deletes all of its descendents.
Since there are likely to be multiple orders, we probably need an implicit or explicit order number, say, (based on the first proposal above):
The style of most M design would remove the text subscripts (column headers) from the data and instantiate them in the code or in another table, perhaps one maintained by a dba tool. Using the above format as an example:
A common technique is to combine "columns" of a "record" into a single node as a string of delimited fields, using order numbers and line numbers, say:
The representations [of "g"] that you (and we) provided are in the form of local variables (in M, local to one process, but extern-like within the process), where a real application would typically use global variables, which are persistent and shared (in the database). This would make the above example:
As you can see, there are lots of possibilities. You may find it interesting to input some data and then use ZWRITE to examine how it gets ordered. Try a KILL and observe how that works.
Think about defining a tool to parse arbitrary XML and stored it using some attractive scheme.
Hope this helps,
Vinaya Revannaswamy for Roger Partridge
Sanchez Computer Associates, Inc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now we use CDS/ISIS (IRBIS), but it does not support transactions, jurnalize etc.
I thought to use GT.M for library program.
And main problem to store MARC-similar data in GT.M is how effective save the position or line number of repeatable fields.
Thanks a lot!
Sorry for my english.
Nodir
Library of Tashkent state technical university
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Temirhodzhaev, in M, repeatable fields are frequently stored using an additional subscript, usually a counter; depending on the need the total count may be stored in the first slot or the parent. Such a design may be sparse or dense, depending on the needs of the application. In a simple example:
^IP(id)=name ;id is the person key or identifier
^IP(id,"A")=count-of-address-lines ;count could also we stored at ^IP(id,"A",0) or not be needed
^IP(id,"A",1)=1st line of address ; all "A" could also be replaced by a code to designate address sub-structure
^IP(id,"A",2)=2nd line of address
^IP(id,"A"...)=more lines of address
^IP(id,"T")=count-of-phone-numbers
^IP(id,"T",phone-number-one)="" ; shows use of data as subscript - causes phone numbers to be ordered
^IP(id,"T",,,) ; same scheme as address might be better - instead of empty string, could use
; text like "home", "cell", or "fax" or could use designations as keys
If the maximum number of repeats is fixed they may be placed in the same node using delimited fields. Such a design is efficient, but less easily modified. Another simple example using the up-bar (|) as the delimiter
^IP(id)=name|address1|address2|address3|address4|address5| ; accommodates up to five lines of address; unused are empty
Hope this helps,
Vinaya Revannaswamy for Roger Partridge
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For example, how to translate some given from xml in GT.M saving order of following:
<Order>
<Item ID="6" Q="2"/>
<Item ID="5" Q="7"/>
<Item ID="8" Q="1"/>
</Order>
Perhaps, so:
g("Order","Item/0","ID")="6";
g("Order","Item/0","Q")="2";
g("Order","Item/1","ID")="5";
g("Order","Item/1","Q")="7";
g("Order","Item/2","ID")="8";
g("Order","Item/2","Q")="1";
But after removing first "Item" we must reorganize data. The data must be such:
g("Order","Item/0","ID")="5";
g("Order","Item/0","Q")="7";
g("Order","Item/1","ID")="8";
g("Order","Item/1","Q")="1";
It isn't effectively :(
Temirhodzhaev, the design of your global is the problem. M databases use a hierarchical topography, rather than the flat tables of a relational database. While this is different, it is not necessarily bad - many problems are in fact hierarchical in nature and work better if laid out that way, rather than in tables. Generally, this go better when you apply the same normalization rules that you would use with a relational system.
g("Order","Item ID",5,"Q")=7
g("Order","Item ID",6,"Q")=2
g("Order","Item ID",8,"Q")=1
Would be on possible representation of the XML input. This is close to what you originally proposed (at least in many ways). It organizes the data by the arriving XML, effectively by Item ID.
If the position or line number is important, then something like (say) this would serve:
g("Order",0,"Item ID")="6";
g("Order",0,"Q")="2";
g("Order",1,"Item ID")="5";
g("Order",1,"Q")="7";
g("Order",2,"Item ID")="8";
g("Order",2,"Q")="1";
This representation and your original one both add an implicit quantity for line number, which is not in the XML input.
Actually, M implicitly addresses the issue of the data organization because the delete (KILL) is a hierarchical operation - deleting a line (or an item id) in your original proposal and the other suggestions, deletes all of its descendents.
Since there are likely to be multiple orders, we probably need an implicit or explicit order number, say, (based on the first proposal above):
g("Order",0,"Item ID",5,"Q")=7
g("Order",0,"Item ID",6,"Q")=2
g("Order",0,"Item ID",8,"Q")=1
The style of most M design would remove the text subscripts (column headers) from the data and instantiate them in the code or in another table, perhaps one maintained by a dba tool. Using the above format as an example:
g(0,5)=7 ; 0th Order, Item ID 5, Quantity 7
g(0,6)=2
g(0,8)=1
The column heading table could be a part of the array, say:
g(-1)="(Order,Item ID)"="Quantity"
g(0,5)=7 ; 0th Order, Item ID 5, Quantity 7
g(0,6)=2
g(0,8)=1
A common technique is to combine "columns" of a "record" into a single node as a string of delimited fields, using order numbers and line numbers, say:
g(0,0)=6|2 ; 0th Order, 0th line, Item ID 6, Quantity 2
g(0,1)=5|7
g(0,2)=8|1
The representations [of "g"] that you (and we) provided are in the form of local variables (in M, local to one process, but extern-like within the process), where a real application would typically use global variables, which are persistent and shared (in the database). This would make the above example:
^g(0,0)=6|2 ; 0th Order, 0th line, Item ID 6, Quantity 2
^g(0,1)=5|7
^g(0,2)=8|1
As you can see, there are lots of possibilities. You may find it interesting to input some data and then use ZWRITE to examine how it gets ordered. Try a KILL and observe how that works.
Think about defining a tool to parse arbitrary XML and stored it using some attractive scheme.
Hope this helps,
Vinaya Revannaswamy for Roger Partridge
Sanchez Computer Associates, Inc
Now we use CDS/ISIS (IRBIS), but it does not support transactions, jurnalize etc.
I thought to use GT.M for library program.
And main problem to store MARC-similar data in GT.M is how effective save the position or line number of repeatable fields.
Thanks a lot!
Sorry for my english.
Nodir
Library of Tashkent state technical university
Temirhodzhaev, in M, repeatable fields are frequently stored using an additional subscript, usually a counter; depending on the need the total count may be stored in the first slot or the parent. Such a design may be sparse or dense, depending on the needs of the application. In a simple example:
^IP(id)=name ;id is the person key or identifier
^IP(id,"A")=count-of-address-lines ;count could also we stored at ^IP(id,"A",0) or not be needed
^IP(id,"A",1)=1st line of address ; all "A" could also be replaced by a code to designate address sub-structure
^IP(id,"A",2)=2nd line of address
^IP(id,"A"...)=more lines of address
^IP(id,"T")=count-of-phone-numbers
^IP(id,"T",phone-number-one)="" ; shows use of data as subscript - causes phone numbers to be ordered
^IP(id,"T",,,) ; same scheme as address might be better - instead of empty string, could use
; text like "home", "cell", or "fax" or could use designations as keys
If the maximum number of repeats is fixed they may be placed in the same node using delimited fields. Such a design is efficient, but less easily modified. Another simple example using the up-bar (|) as the delimiter
^IP(id)=name|address1|address2|address3|address4|address5| ; accommodates up to five lines of address; unused are empty
Hope this helps,
Vinaya Revannaswamy for Roger Partridge