<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Data on Prosyon Research</title><link>https://research.prosyon.ca/topics/data/</link><description>Recent content in Data on Prosyon Research</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 28 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://research.prosyon.ca/topics/data/index.xml" rel="self" type="application/rss+xml"/><item><title>A Single-Table DynamoDB Model</title><link>https://research.prosyon.ca/papers/single-table-dynamodb/</link><pubDate>Tue, 28 Apr 2026 00:00:00 +0000</pubDate><guid>https://research.prosyon.ca/papers/single-table-dynamodb/</guid><description>&lt;h2 id="why-single-table"&gt;Why single-table&lt;/h2&gt;
&lt;p&gt;Relational instincts say &amp;ldquo;one table per entity.&amp;rdquo; DynamoDB rewards the opposite:
co-locating related entities in a single table lets you satisfy a query with one
request and no joins.&lt;sup id="fnref:1"&gt;&lt;a href="#fn:1" class="footnote-ref" role="doc-noteref"&gt;1&lt;/a&gt;&lt;/sup&gt; The cost is up-front design effort — you must know
your access patterns &lt;em&gt;before&lt;/em&gt; you choose keys.&lt;/p&gt;</description></item></channel></rss>