DynamoDB每日时间范围存储方案设计合理性咨询

Hey there! Let's break down your approach to storing daily time windows for event trigger checks, and talk about how to make it more elegant plus work around the resource creation limitation.

What’s Great About Your Current Approach #

• Simple calculations: To check if an event (like a user login) falls in a window, just convert the event time to total minutes since midnight (hours * 60 + minutes) and compare against your intervals. No messy date/time parsing or timezone conversions needed.
• Lightweight storage: Storing numbers (or numeric strings) takes way less space than full timestamps or date strings, and serializes/deserializes quickly.
• No timezone gotchas: Since everything is relative to the start of the day, you don’t have to worry about daylight saving shifts or cross-timezone mismatches.

Tweaks for More Elegance #

1. Rename for Clarity #

duration-timestamp is a bit misleading—"timestamp" usually refers to an absolute point in time, not a relative minute count. Try something like daily-time-windows or daytime-intervals instead. For the inner keys, start_minute and end_minute are more precise than start_time/end_time (since we’re dealing with minutes, not full timestamps).

2. Use Numeric Types Instead of Strings #

If your backend supports it, ditch the quoted numbers ("360") and use raw integers (360). This avoids unnecessary type conversion when running checks and makes the data structure more intuitive:

"daily-time-windows": [
  { "start_minute": 360, "end_minute": 600 },
  { "start_minute": 960, "end_minute": 1200 }
]

3. Add Validation Guardrails #

To prevent bad data (like a start minute being later than an end minute, or values over 1439—since there are 1440 minutes in a day), add validation logic when writing this attribute:

• Ensure start_minute < end_minute for every interval
• Restrict values to the 0–1439 range
• Optional: Auto-merge overlapping intervals if you don’t want redundant windows

4. Wrap Check Logic in a Reusable Function #

Turn the time window check into a utility function to keep your code clean and DRY. Here’s a quick example in JavaScript:

function isWithinDailyWindows(currentDate, timeWindows) {
  const currentMinute = currentDate.getHours() * 60 + currentDate.getMinutes();
  return timeWindows.some(window => {
    return currentMinute >= window.start_minute && currentMinute <= window.end_minute;
  });
}

Working Around "Can’t Create New Resources" #

If you can’t spin up a dedicated resource (like a database table or document) for these time windows, here are a few options:

• Embed it in an existing resource: If these windows are tied to a specific entity (like a user account or a trigger rule), just keep the daily-time-windows attribute as part of that entity’s data—this is exactly what you’re planning, and it’s a totally valid approach.
• Use a config file: If the windows are global (same for all users/triggers), store them in a config file (e.g., app-config.json) that loads into memory when your app starts. No database changes needed.
• Reuse an existing field (last resort): If you can’t add any new fields at all, you could serialize the window data into a string and stuff it into a generic "notes" or "metadata" field—but this is messy and hard to maintain, so only do this if you have no other choice.

Final Thought #

Your core approach is strong—with a few small naming and validation tweaks, it’ll be both elegant and robust. And if resource creation is off the table, embedding the windows in an existing entity is the most straightforward solution.

内容的提问来源于stack exchange，提问作者Enigma girl