# Database structure : rows vs columns **URL:** \ **Category:** Ask for Help\ **Created:** [July 22, 2023, 10:14pm UTC](https://community.glideapps.com/t/database-structure-rows-vs-columns/64274 "2023-07-22T22:14:48Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![AyS\_0908](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/ays_0908/32/27349_2.png) [@AyS\_0908](https://community.glideapps.com/u/AyS_0908)\ **Post date:** [July 22, 2023, 10:14pm UTC](https://community.glideapps.com/t/database-structure-rows-vs-columns/64274/1 "2023-07-22T22:14:48Z")
Hi, (I asked a close question about this topic in the past, but given the evolutions of Glide, I re-ask it). I am building a self-diagnosis tool where people can assess themselves per _Task_. These _Tasks_ are setup with the following structure: Category A \> Sub Category Aa \> _Task_ Aa1. There are a dozen Categories, a hundred Sub Categories and a thousand _Tasks_. The assessment will be something like ‘high, medium, low’ + ‘comments’. **Constraints** (remembering some questions of @Jeff_Hager on this topic) : - Users must be able to come back on their assessment and modify it, - I should be able to make analysis on the whole set of users input (ex. comparaison to the average), - Multiple users should be able to performer the dizg osis at the same time, - I can use form or customer form, - I can have all questions on 1 page or not **Database structure** : Given the number of _Task_ my view (without your expertise in such structuration) is to have 1 Task per Row: easier to input, to maintain, to assign calcilations etc. This means 1 row per User per _Task_. Drawback: rows consumption. Do you have an alternative view on how to structure this database ? A y other good pièces of advice ? Many thanks in advance ---
**Author:** ![nathanaelb](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/nathanaelb/32/43079_2.png) [@nathanaelb](https://community.glideapps.com/u/nathanaelb)\ **Post date:** [July 25, 2023, 8:08am UTC](https://community.glideapps.com/t/database-structure-rows-vs-columns/64274/2 "2023-07-25T08:08:41Z")
Hello there 👋 > [@AyS\_0908](#): > > There are a dozen Categories, a hundred Sub Categories and a thousand _Tasks_. 10x100x1000 is 1 million tasks, 1 million rows. Multiplied by the number of users. Pre-Big Tables, I would not have liked those numbers. Now, I would think this might be a good use case for Big Tables and I’d go there with caution (I have zero experience with them). Big Tables have limitations, so already I feel like your app would be limited either in scaling or features (due to the limitations of Big Table), and this by design. > [@AyS\_0908](#): > > I should be able to make analysis on the whole set of users input (ex. comparison to the average) This sounds like you are going to need to do rollups on a sizeable data set. You can do rollups in a Big Table along basic column (not computed columns). > [@AyS\_0908](#): > > Do you have an alternative view on how to structure this database ? - I would go down the route of Big Tables. - Category + Sub-categories. If these have the same attributes (basic columns), I would keep them in one table with parent and child columns. If the attributes are different (things in things), I would have a categories table and a separate sub-categories table. Then probably a separate tasks table. Tables would be connected with relations. > [@AyS\_0908](#): > > Any other good pieces of advice ? You could make sure you understand the limitations of Big Tables if you go down that route. > **[Big Tables](https://www.glideapps.com/docs/essentials/data-sources/big-tables)** > > Scale your app with up to 10 million rows of data. ---
**Author:** ![AyS\_0908](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/ays_0908/32/27349_2.png) [@AyS\_0908](https://community.glideapps.com/u/AyS_0908)\ **Post date:** [July 25, 2023, 10:05am UTC](https://community.glideapps.com/t/database-structure-rows-vs-columns/64274/3 "2023-07-25T10:05:31Z")
> [@nathanaelb](#): > > Category + Sub-categories. If these have the same attributes (basic columns), I would keep them in one table with parent and child columns. If the attributes are different (things in things), Many thanks @nathanaelb, the point that you mentionned on “category + sub category” is a question that I often have. I basically always create 2 different tables with a relation link, because I don’t know when it is unnecessary. cf. your “things in things”. Best ---
**Author:** ![nathanaelb](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/nathanaelb/32/43079_2.png) [@nathanaelb](https://community.glideapps.com/u/nathanaelb)\ **Post date:** [July 25, 2023, 11:16am UTC](https://community.glideapps.com/t/database-structure-rows-vs-columns/64274/4 "2023-07-25T11:16:51Z")
That’s a great point. I’m not a programmer by trade, programmers probably have clear criteria to determine when to have one single table for items, and when to have different tables. The way I see it practically in Glide: - If items (or objects) are related to each other and they are clearly the same object and there would be subcategories, then one table. Basically I could categorize the objects as a tree. Example: Employees at a company. They are all people, I can create a tree structure to show hierarchy, this hierarchy is built with parent and child columns. Other examples: Tasks. Products. Supplies. - If items or objects are related to each other and they are clearly _not_ the same object and there would be groups of objects, then multiple tables. I think the visual structure is more like a network or fractal (not a neat tree). Example: Employees and their locations. Clearly, a person is not the same as a location. In theory, you could define the same attributes (a name, description, image, etc.), put both people and locations in the same table and say they belong in the same table because they have the same attributes (a name, description, image, etc.), but really, they are not the same. This viewpoint is flimsy, because it’s obvious for people and locations, but it could be less obvious for other objects. There’s probably a better explanation as to why people and locations are actually not the same 🙂 ---
**Author:** ![AyS\_0908](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/ays_0908/32/27349_2.png) [@AyS\_0908](https://community.glideapps.com/u/AyS_0908)\ **Post date:** [July 26, 2023, 8:36am UTC](https://community.glideapps.com/t/database-structure-rows-vs-columns/64274/5 "2023-07-26T08:36:59Z")
Good point of view! Thanks Best