Database Schema Modeling Questions

leordevleordev Posts: 7 Brand New

Hello folks! I'm new to EOS and DApps world! I'm a fullstack developer coming from a java and javascript experience, and also some functional programming plays :)

For some reason I cannot post to Developers category... the only categories enabled for me are Constitution, Governance and Testnet. So I've chosen Testnet as the closest one to my topic subject, but if you can, please move to developers! :tongue:

That said, I'd like your help in my database schema. I'm trying to create a table for Places that's related to a PlaceType table. It's just places with their address grouped by types (i.e. coffeshops, libraries, houses etc.).

This is my original schema when working with GraphQL:

// Table Places
type Place @model {
  id: ID! @isUnique
  name: String!
  description: String!
  latitude: Float!
  longitude: Float!
  address: String!
  address2: String
  city: String!
  state: String!
  zip: String!
  country: String!
  phone: String
  email: String
  url: String
  type: PlaceType! @relation(name: "PlacesTypes")
  createdBy: User! @relation(name: "UserPostedPlaces")
  images: [String!]

// Table PlaceTypes
type PlaceType @model {
  id: ID! @isUnique
  name: String!
  places: [Place!]! @relation(name: "PlacesTypes")

Now, if I want to reflect this relationship into EOS smart contracts, that's what I'm trying to build but I'm not sure... Can you please help me?

struct PACKED(place) {
    place() {};
    place(char* name, char* description,
      uint128_t latitude, uint128_t longitude,
      char* address, char* address2, char* city,
      char* state, char* zip, char* country,
      char* phone, char* email, char* url,
      uint128_t place_type_id, account_name created_by):name(name),
      description(description), latitude(latitude), longitude(longitude),
      address(address), address2(address2), city(city),
      state(state), zip(zip),country(country),
      phone(phone), email(email), url(url),
      place_type_id(place_type_id), created_by(created_by) {};

    uint128_t id;

    char* name;
    char* description;

    uint128_t latitude;
    uint128_t longitude;
    char* address;
    char* address2;
    char* city;
    char* state;
    char* zip;
    char* country;

    char* phone;
    char* email;
    char* url;

    uint128_t place_type_id;

    account_name created_by;


  struct PACKED(place_type) {
    place_type() {}
    place(char* name):name(name) {};

    uint128_t id;
    char* name;

  using Places =

  using PlaceTypes =

So, here are my questions:

1) I'm using char* for text fields because I found it on storage.hpp contract example on link structure. Is it correct? Does char* supports big texts like 20k chars?

2) Can I store float or should I use uint128_t for any float that I need, like latitudes and longitudes? Do we have any resource, wiki, any document, with all allowed database field types?

3) As you can notice I'm doing the relationship from place to place types with place_type_id field on places table. Is it correct? If you see my PlaceType object on GraphQL schema it has a list of places, which is nothing more than a sugar for my relationship... So in EOS if I want to list all the places for a specific place type, how can I do that?

4) If you check my Place object from GraphQL it has a field called images, which is a list of images url addresses for the corresponding place... How could I do that? I can see in tic_tac_toe that field board is a list of 9 integers. The problem in my case is that I don't have any predefined number of images for my places... It can be 3, 9, 20, nothing etc. Otherwise I imagine that I could just have a list of char*... Anyways, what's the best way to handle this?

5) Now the last one... My project has something around 15 tables... Should I split tables in different smart contracts? Do we have any example for that? What's the best practice in this matter?

That's all folks! I know it's a lot but hopefully I can get some directions to build properly in this amazing platform!

Thank you!!!


  • KevKev Posts: 387 admin

    Closed thread on request from @leordev - he wants to break the question into smaller threads.

This discussion has been closed.