#community-help

Advice on Best Method to Store Event Records

TLDR Matthew requests advice on how to store event records with multiple attendees. Jason suggests storing these records at the event level.

4mo

Join the chat

Jul 26, 2023 (4 months ago)

Photo of md5-ac3436827bebcd62308d83f3823df584

Matthew

05:29 PM

Question about a large number smaller records vs a small number of larger records.
We have a case where we search events but filter by attendees. We have traditionally stored these as attendee records with some event data on each record since the services we used limited the record size. However there is not many events, the collection would be less than 10,000 event records. Most events have a few hundred attendees, but can get up to a few thousand. Would it be better to store events and then attach a list of attendees to each event or continue storing them as attendees with event data on each? We'd prefer to store larger event records with attendees since it's much easier for use to manage and sync the data that way.

Photo of md5-8813087cccc512313602b6d9f9ece19f

Jason

05:39 PM

The answer to this would depend on how you’ll be searching through the data.

I’m guessing you’ll be searching for attendee names, given an event ID?

05:40

Jason

05:40 PM

Do you also search on event details across all events?

Matthew

05:41 PM

Generally we are searching by event names and details(description, speakers, location, etc) and filter out events that the user isn't invited to(no attendee record)

Jason

05:43 PM

Would this be a good simplified version of a potential record:

{
  "event_name": "xyz",
  "event_location": "abc",
  "event_starts_at": 123,
  "event_ends_at": 234,
  "attendee_user_ids": [6, 7, 8, 9]
}

Matthew

05:43 PM

Yes

Jason

05:44 PM

Great, so yeah, you should be good to store events as top level records… especially if the only attendee-level query you’re doing is whether an attendee is part of an event or not

Matthew

05:45 PM

Awesome, thanks for the help

Typesense

Lightning-fast, open source search engine for everyone | Knowledge Base powered by Struct.AI

Indexed 3015 threads (79% resolved)

Join Our Community

Similar Threads

Improving Record Retrieval Speed from Typesense

Yoshi sought ways to accelerate Typesense record retrieval. Jason advised upgrading to high availability and using the documents/export endpoint. They also noted a high volume of writes consuming significant CPU capacity as a possible performance factor.

3mo

Discussions on Typesense, Collections, and Dynamic Fields

Tugay shares plans to use Typesense for their SaaS platform and asks about collection sizes and sharding. Jason clarifies Typesense's capabilities and shares a beta feature. They discuss using unique collections per customer and new improvements. Kishore Nallan and Gabe comment on threading and data protection respectively.

35mo

Discussing Data Retrieval in Typesense Cloud Tool

Ricardo inquired about the impact of using non-searched fields in data records with Typesense. Jason explained that all fields are fetched from the disk, even if unindexed, pointing out it might not affect performance, with the benefit of reducing separate database API calls.

33mo

Database Management and Personalized Search Queries Discussion

Alexander posed several database and search-related questions. Mac suggested considering GraphQL, considering performance and high availability needs, and leveraging Cloudflare workers. Kishore Nallan provided insights on the capabilities of Typesense and discussed the idea of search personalization using machine learning.

20mo

Handling Field Variations in Typesense for Different Clients

Yoshi asked for a solution to handle varying contact_date fields for different clients in typesense. Jason recommended using nested fields for the short-term and mentioned future support for joining data across collections.

7mo