nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Transpose rows from a table as attribute fields in a feature class

ialixandroae

Hello,

Could someone help me with this issue? I want to transpose all the rows from a table as attribute fields in a feature class and I find it difficult to do for almost 500 tables and 500 rows in the feature class.

So practically I want to avoid doing a relationship class and move the data like this:

Table

------------------------------------------------

Type | Surface | Name |

A | 11 | Name1|

B | 12 | Name 2|

n | n | Name"n"|

And those multiple rows I want to move in a feature class and the feature class`s attribute table to become like this:

1 | 1212121 | A | 11 | Name1| B | 12 | Name2|.............| 'n' | ..... | ......... |

Hope you understand:)

Thanks,

Ionut

Najděte více příspěvků označených jako

Accepted answers

ialixandroae

Hello all

Well I solved the problem by using in a model a tool named "Pivot Tabel" - this tool practically transposed all my rows in columns which is all I needed. After that I merged all the tables that were "pivoted" and after that managed to join that 1 table resulted to the feature class

Thank you very much for the responses and fast feedback,

Ionut

All comments

hhet

Re : are tables really feature classes?

in a review of geodatabse fundamentals:

---as was said earlier, the geographic representation of an object - feature is stored as one of its columns (fields) in the row. the name of the field might be "geometry"

----a feature class is managed in a single table

---in a feature class table each feature class is managed as a table

---one can create feature classes aka spatial tables

---one can create feature classes from xy tables

It appears that the two are not entirely interchangable but dependent on each other.

Question is: Is the converse of the original statement true, false or utter nonsense?

ialixandroae

Hello all

Thank you very much for the responses and fast feedback,

Ionut

RichardFairhurst

In general I agree. Also, if this is about creating labels from a set of related tables that have a 1:M relationship then do the technique shown in my Blog on that subject. it is fast enough and much easier to maintain the data than violating the data normalization pattern even more than you already have with 500 separate tables. My blog approach is based on a table structure exactly like what Vince suggested and can respect the subset query he suggested for each surface type so that all 500 tables can combined into a single table with 3 or 4 fields and still create the labels as though they were in a single row with many field columns (even better since it creates no wasted field columns ever and can maintain a data sort for you that is nearly impossible with columns).

VinceAngelo

The power of databases is harnessed through rows, not tables. Creating "One table per record in feature class" is an easy way to cripple any database (even 250,000 files in one directory will cripple effective file system operation, and file systems are designed to hold more files than databases are designed to hold tables.).

I strongly recommend you go back to the design stage and plan something less brutal to effective database operation. The simplest solution is to populate ONE table, organized {ID,Type,Name}, index the table on ID, and use queries that state "SELECT Type,Name FROM table WHERE ID= n"

- V

ialixandroae

Let`s say that you have tables regarding CLC ( Corine Land Cover) type, surface and name of the state for each of the USA states and also you have a feature class ( polygon) with 50 records with USA states. You would like to add 1 table information for 1 record in feature class. So practically to be able to find for each state of USA the types of CLC and also the surface of each of those types. Hope it`s not more confusing now...

Also, I do not want to use relations/relationship classes...

Thanks,

Ionut

RichardFairhurst

Well 60 fields is somewhat manageable. However, I am still not understanding what you are working with. Ignore the tables for a moment. What is the feature class like that relates to these 500 tables? Does it contain 500 features?

If the 500 table contain different field names then you could still end up with a huge number of fields. Combining all tables together into a single feature class would result in 500 tables * 60 fields each = 30,000 fields.combined. Do you intend to end up with 500 separate feature classes, or do all 500 table contain the same set of fields? If they contain the same set of fields, why did you create 500 tables in the first place?

It would help if I had a clue what kind of data this is and a practical example of one table relationship to your feature class. I.e, There are n features which are agricultural fields and each table contains separate monthly sample data by crop type. Leaving everything abstract is not helping me even imagine a scenario that would produce the kind of data you are working with.

ialixandroae

Here`s a schema for better understanging

ialixandroae

Hi Richard,

Well, I would like to add 60 more fields into that feature class and those 60 fields to be populated with the data from those 500 tables. 500 tables for 500 records in that feature class( each table would have 30 rows and 2 fields that would mean 60 fields per record to be added and populated).

Ionut

RichardFairhurst

Are you saying you want to combine 500 tables, 500 rows and at least 3 fields per row into 1 row? That is 750,000 fields in a single row. The maximum number of fields you can have in a dbf table or shapefile is 255 fields. The maximum number of fields you can have in an FGDB table or feature class is 65,534 fields. So you cannot do what you seem to have described regardless of the tools you use.

Additionally, even if you could do this, once you get beyond about 30 rows transposed, it becomes virtually impossible at a practical level to write any SQL logic against the table or compose a label expression to make selective use of specific fields based on the values they contain. So even if you can create what you say you want, it may turn out to not work at a practical level in the end, depending on what you intend to do with this feature class/table.

ialixandroae

I was thinking about that but it doesn`t help me in this situation...

Thanks,

Ionut

KishorGhatage

Try using Transpose tool:

ArcGIS Help (10.2, 10.2.1, and 10.2.2)

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.