TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Things to know about databases

730 点作者 grech将近 3 年前

23 条评论

SulphurSmell将近 3 年前
This article is informative. I have found that databases in general tend to be less sexy than the front-end apps...especially with the recent cohort of devs. As an old bastard, I would pass on one thing: Realize that any reasonably used database will likely outlast the applications leveraging it. This is especially true the bigger it gets, and the longer it stays in production. That said, if you are influencing the design of a database, imagine years later what someone looking at it might want to know if having to rip all the data out into some other store. Having migrated many legacy systems, I tend to sleep better when I know the data is well-structured and easy to normalize. In those cases, I really don&#x27;t care so much about the apps. If I can sort out (haha) the data, I worry less about the new apps I need to design. I have been known to bury documentation into for-purpose tables...that way I know that info won&#x27;t be lost. Export the schema regularly, version it, check it in somewhere. And, if you can, <i>please</i>, limit the use of anything that can hold a NULL. Not every RDBMS handles NULL the same way. Big old databases live a looooong time.
评论 #31900780 未加载
评论 #31898422 未加载
评论 #31898789 未加载
评论 #31902981 未加载
评论 #31901658 未加载
评论 #31898610 未加载
评论 #31902367 未加载
评论 #31901268 未加载
评论 #31903661 未加载
评论 #31902601 未加载
评论 #31918939 未加载
yla92将近 3 年前
Great post. Also highly recommend Designing Data-Intensive Applications by Martin Kleppmann (<a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Designing-Data-Intensive-Applications-Reliable-Maintainable&#x2F;dp&#x2F;1449373321" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Designing-Data-Intensive-Applications...</a>). The sections on &quot;Storage and Retrieval&quot;, &quot;Replication&quot;, &quot;Partitioning&quot; and &quot;Transactions&quot; really opened up my eyes!
评论 #31896245 未加载
评论 #31897488 未加载
tiffanyh将近 3 年前
#1 thing you should know, RDBMS can solve pretty much every data storage&#x2F;retrieval problem you have.<p>If you&#x27;re choosing something other than an RDBMS - you should rethink why.<p>Because unless you&#x27;re at massive scale (which still doesn&#x27;t justify it), choosing something else is rarely the right decision.
评论 #31898111 未加载
评论 #31898604 未加载
评论 #31897780 未加载
评论 #31897988 未加载
评论 #31897673 未加载
评论 #31898889 未加载
评论 #31898141 未加载
评论 #31897812 未加载
评论 #31898003 未加载
评论 #31905274 未加载
评论 #31897356 未加载
评论 #31904684 未加载
评论 #31901623 未加载
评论 #31897554 未加载
评论 #31905465 未加载
评论 #31898990 未加载
Merad将近 3 年前
&gt; a dirty read occurs when you perform a read, and another transaction updates the same row but doesn&#x27;t commit the work, you perform another read, and you can access the uncommitted (dirty) value<p>It&#x27;s even worse than this with MS SQL Server. When using the READ UNCOMMITTED isolation level it&#x27;s actually possible to read corrupted data, e.g. you might read a string while it&#x27;s being updated, so the result row you get contains a mix of the old value and new value of the column. SQL Server essentially does the &quot;we got a badass over here&quot; Neil deGrasse Tyson meme and throws data at you as fast as it can. Unfortunately I&#x27;ve worked on several projects where someone apparently thought that READ UNCOMMITTED was a magic &quot;go fast&quot; button for SQL and used it all throughout the app.
评论 #31901086 未加载
AtNightWeCode将近 3 年前
Not sure how to use these recommendations in practice though even if the info is somewhat correct. SQL is a beast of tech and it is used because of battle history and since there is simply no other viable tech replacing it when it comes to transactions and aggregated queries.<p>Indexes are a nightmare to get right. Often performance optimizations of SQL databases include removing indexes as much as adding indexes.
评论 #31897391 未加载
评论 #31897369 未加载
donatj将近 3 年前
I still think about my first job out of college. Shopping cart application, we would add indexes exclusively <i>when there was a problem</i> rather than proactively based on expected usage patterns. It&#x27;s genuinely a testament to MySQL that we got as far as we did without knowing anything about what we were doing.<p>One of my most popular StackOverflow questions to this day is about how to handle <i>one million</i> rows in a single MySQL table (<i>shudder</i>).<p>The product I work on now collects more rows than that <i>a day</i> in a number of tables.
mjb将近 3 年前
Introductory material is always welcome, but I suspect this isn&#x27;t going to hit the target for most people. For example:<p>&gt; Therefore, if the price isn’t an issue, SSDs are a better option — especially since modern SSDs are just about as reliable as HDDs<p>This needs a tiny extra bit of detail: if you&#x27;re buying random IO (IOPS) or throughput (MB&#x2F;s), SSDs are significantly (orders of magnitude!) cheaper than HDDs. HDDs are only cheaper on space, and only if your need for throughput or IO doesn&#x27;t cause you to &quot;strand&quot; space.<p>&gt; Consistency can be understood after a successful write, update, or delete of a row. Any read request immediately receives the latest value of the row.<p>This isn&#x27;t the ACID definition of C, and is closer to the distributed systems (CAP) one. I can&#x27;t fault the article for getting this wrong, though - it&#x27;s super confusing!
评论 #31897467 未加载
thedougd将近 3 年前
I have to plug the &quot;Designing Data-Intensive Applications&quot; book. It dives deep into the inner workings of various database architectures.<p><a href="https:&#x2F;&#x2F;dataintensive.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dataintensive.net&#x2F;</a>
wrs将近 3 年前
From the SERIALIZABLE explanation: “The database runs the queries one by one … It is essential to have some retry mechanism since queries can fail.”<p>I know they’re trying to simplify, but this is confusing. If the first part is true, the second part can’t be. In reality the database does execute the queries concurrently, but will try to make it <i>seem</i> like they were done one by one. If it can’t manage that, a query will fail and have to be retried by the application.
评论 #31896536 未加载
bironran将近 3 年前
Nice post, though for the indexing &quot;introduction-deep-dive&quot; I would still recommend newbies to look at <a href="https:&#x2F;&#x2F;use-the-index-luke.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;use-the-index-luke.com&#x2F;</a> .
评论 #31898394 未加载
评论 #31896826 未加载
jwr将近 3 年前
Some of the explanations are questionable: I think they were overly simplified, and while I applaud the goal, some things just aren&#x27;t that simple.<p>I highly recommend reading <a href="https:&#x2F;&#x2F;jepsen.io&#x2F;consistency" rel="nofollow">https:&#x2F;&#x2F;jepsen.io&#x2F;consistency</a> and clicking on each model on the map. This is the best resource I found so far for understanding databases, especially distributed ones.
评论 #31897561 未加载
评论 #31897049 未加载
galaxyLogic将近 3 年前
<a href="https:&#x2F;&#x2F;github.com&#x2F;prql&#x2F;prql" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prql&#x2F;prql</a> :<p>&quot; Unlike SQL, it forms a logical pipeline of transformations, and supports abstractions such as variables and functions. It can be used with any database that uses SQL, since it transpiles to SQL. &quot;
jandrewrogers将近 3 年前
&gt; &quot;Scale of data often works against you, and balanced trees are the first tool in your arsenal against it.&quot;<p>An ironic caveat to this is that balanced trees don&#x27;t scale well, only offering good performance across a relatively narrow range of data size. This is a side-effect of being &quot;balanced&quot;, which necessarily limits both compactness and concurrency.<p>That said, concurrent B+trees are an absolute classic and provide important historical context for the tradeoffs inherent in indexing. Modern hardware has evolved to the point where B+trees will often offer disappointing results, so their use in indexing has dwindled with time.
评论 #31897829 未加载
评论 #31908230 未加载
评论 #31897791 未加载
jrm4将近 3 年前
To go big picture; I&#x27;m kind of glad databases are largely like cars in this respect, in ways that other software tooling isn&#x27;t.<p>Which is to say they&#x27;re frequently good enough such that the human working with them on whatever level can safely <i>not know</i> a lot of these details and get a LOT done. Kudos to whoever deserves them here.
评论 #31897893 未加载
googletron将近 3 年前
This is a quick rundown of database indexes and transactions. Excited to continue sharing these notes with community!
评论 #31896203 未加载
trhoad将近 3 年前
An interesting subject! The article could do with an edit, however. There are lots of grammatical errors.
molly0将近 3 年前
Anyone read this pdf&#x2F;book <a href="https:&#x2F;&#x2F;sql-performance-explained.com" rel="nofollow">https:&#x2F;&#x2F;sql-performance-explained.com</a> and would recommend?
r0b05将近 3 年前
Nicely written and informative!
评论 #31896752 未加载
manish_gill将近 3 年前
What tool was used to create the visuals?
评论 #31902559 未加载
sonofacorner将近 3 年前
This is great. Thanks for sharing!
dennalp将近 3 年前
Really nice guide.
otherflavors将近 3 年前
why is this tagged &quot;MySQL&quot; but not also &quot;SQL&quot;
评论 #31896633 未加载
throwaway787544将近 3 年前
Can anyone give me a brief understanding of stored procedures and when I should use them?