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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Time for a WTF MySQL Moment

327 点作者 gbl08ma超过 4 年前

18 条评论

munk-a超过 4 年前
I&#x27;m a big fan of Postgres too for a number of reasons, but this issue is pretty clearly documented so I&#x27;d like to counter with an issue I hit in Postgres recently that is <i>terribly</i> documented. UNNEST works a bit funky, and in particular it works super funky if you have multiple calls in the same select statement (or any set expanded function calls it turns out). There&#x27;s a bit of a dive into here[1] (though that is out of date - PG10 no longer follows the different array sized result, it uses null filling) which I managed to find after struggling with an issue where an experimental query was resulting in nulls in the output while unnesting arrays without nulls.<p>All DBs have their warts and while MySQL has an over abundance of warts they tend to be quite well documented. The warts that postgres has tend to be quite buried and their documentation is very good for syntax comprehension but rather light when it comes to deeper learning.<p>1. <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;50364475&#x2F;how-to-force-postgresql-cartesian-product-behavior-when-unnesting-multiple-ar" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;50364475&#x2F;how-to-force-po...</a>
评论 #24700634 未加载
评论 #24700283 未加载
评论 #24700301 未加载
simias超过 4 年前
&gt; This format is even less wieldy than the current one, requiring multiplication and division to do basically anything with it, except string formatting and parsing – once again showing that MySQL places too much value on string IO and not so much on having types that are convenient for internal operations and non-string-based protocols.<p>Not necessarily an odd choice in the Olden Days, after all BCD representation used to be pretty popular. By modern standards it&#x27;s insane, but at a time where binary to decimal conversions could be a serious performance concern it might have made sense. For instance if you had a date in &quot;hours, minutes, seconds&quot; and wanted to add or subtract one of these TIME values, you could do it without a single multiply or divide.<p>Now I was 8 when MySQL first released in 1995, so I can&#x27;t really comment on whether that choice really made sense back then. 1995 does seem a bit late for BCD shenanigans, but maybe they based their design on existing applications and de-facto standards that could easily go back to the 80&#x27;s.
评论 #24700632 未加载
评论 #24702054 未加载
njharman超过 4 年前
This is going to sound insulting, maybe it is, sorry. It&#x27;s definitely subjective.<p>The reason I reach for Postgres over MySQL isn&#x27;t features or technical superiority. Although those result from the reason. Which is, PG devs consistently have &quot;taste&quot;, they have &quot;good&quot; style. They make good choices. MySQL devs are not consistently strong in these areas. I&#x27;m guessing that MySQL is now so full of tech and design debt (like OP issue) that they&#x27;re just stuck, without choice.
评论 #24703834 未加载
评论 #24702426 未加载
评论 #24714813 未加载
xeeeeeeeeeeenu超过 4 年前
A list of MySQL WTFs: <a href="https:&#x2F;&#x2F;grinnz.com&#x2F;stuff&#x2F;lolmysql.txt" rel="nofollow">https:&#x2F;&#x2F;grinnz.com&#x2F;stuff&#x2F;lolmysql.txt</a>
评论 #24700276 未加载
评论 #24700864 未加载
评论 #24700713 未加载
评论 #24704540 未加载
评论 #24704776 未加载
eska超过 4 年前
This gives me flashbacks to the DOS filesystem timestamps. It&#x27;s exactly the same mistake. By splitting the date into multiple fields, bits are wasted. If they hadn&#x27;t tried to be smart and just made it one number, it would&#x27;ve been more precise with a wider range.
评论 #24703504 未加载
评论 #24699924 未加载
评论 #24700714 未加载
jarym超过 4 年前
MySQL has come a long long way indeed but not enough to make me turn away from Postgres.
评论 #24701583 未加载
评论 #24715207 未加载
josefx超过 4 年前
&gt; 1 bit sign (1= non-negative, 0= negative)<p>First time I ever saw a number where the leading sign bit has to be set to 1 to indicate non-negative.
评论 #24699652 未加载
评论 #24699608 未加载
nitramt超过 4 年前
That&#x27;s yet another incompatibility with the ISO&#x2F;ANSI SQL specification. In the specification, the TIME type is defined as containing HOUR, MINUTE and SECOND fields, representing the &quot;hour within day&quot;, &quot;minute within hour&quot; and &quot;second within minute&quot; values, respectively, so, the valid range for that type supposed to be &quot;00:00:00:00.00000...&quot; to &quot;23:59:59.99999...&quot;. It&#x27;s not intended to represent an interval, although that seems to be the intended semantics for MySQL&#x27;s TIME type:<p>(from <a href="https:&#x2F;&#x2F;dev.mysql.com&#x2F;doc&#x2F;refman&#x2F;8.0&#x2F;en&#x2F;time.html" rel="nofollow">https:&#x2F;&#x2F;dev.mysql.com&#x2F;doc&#x2F;refman&#x2F;8.0&#x2F;en&#x2F;time.html</a>):<p>&gt; but also elapsed time or a time interval between two events (which may be much greater than 24 hours, or even negative).<p>For representing temporal intervals, the specification defines two kinds of INTERVAL types (year-month and day-time). Year-month intervals can represent intervals in terms of years, months, or a combination of years and months. Similarly, day-time interval, can represent intervals in terms of days, hours, minutes or seconds, or combinations of them (e.g, days+hours, days+hours+minutes, hours+minutes, etc.)<p>As a sidenote, the TIME and DATE types are related to the TIMESTAMP type in that TIMESTAMP can be thought of as combination of a DATE part (year, month, day) and a TIME (hour, minute, second) part.
评论 #24705927 未加载
gigatexal超过 4 年前
Here’s a Redshift oddity that I don’t think is documented:<p>select sum(y.a), count(y.a) from(select distinct x.a from ( select 1 as a union all select 2 as a union all select 1 as a)x)y<p>sum | count -----+------- 4 | 3<p>Sqlite3 returns the correct results of sum of 3 count of 2.<p>To fix this don’t use subqueries.
评论 #24705936 未加载
TedShiller超过 4 年前
I gave up on MySQL a long time ago, when I realized that I had to activate special types of settings just to make Unicode characters work in tables.<p>In Postgres, it just works out of the box.
评论 #24703607 未加载
sfilargi超过 4 年前
“I am struggling to imagine the circumstances where ..... can break ....”<p>If only I had a penny for everyone I heard this argument and we ended up breaking regression tests or something really obscure in the qa or customer setup
评论 #24704967 未加载
评论 #24704947 未加载
评论 #24705204 未加载
smeeth超过 4 年前
I have yet to find a situation where using a native datetime format made more sense than using a unix timestamp in integer fields.
评论 #24701955 未加载
crazygringo超过 4 年前
Ultimately this is a bit of a rant about why MySQL didn&#x27;t bother changing the TIME type to support an elegant maximum value of 1,024 hours instead of 838.<p>But, seriously? Who cares? It&#x27;s not even close to an extra order of magnitude of range. The type is obviously meant to be used for time values that have a context of hours within a day, supporting a few days as headroom... so supporting 1,024 instead of 838 is pointless -- if you&#x27;re getting anywhere even close to the max value, you probably shouldn&#x27;t be using this type in the first place.<p>And yes, it&#x27;s probably <i>best</i> not to change it for backwards compatibility. Can I imagine a case where it could break something? No, not off the top of my head. But it <i>probably</i> would break some application somewhere. And for such a widely deployed piece of critical foundational infrastructure, being conservative is the way to go.<p>Nothing about this seems WTF at all, except for the author&#x27;s seeming opinion that elegant, power-of-two ranges ought to trump backwards compatibility with things that probably made sense at the time.
jmnicolas超过 4 年前
IIRC there was also another problem with MySQL and .NET: MySQL used the year 0 as an uninitialized DateTime but .NET starts at year 1.<p>I think the workaround was to pass some parameter in the connection string.
mikorym超过 4 年前
TL;DR<p>So the answer is just it&#x27;s for backwards compatibility with MySQL 3?<p>I was kind of hoping for more.
falcolas超过 4 年前
So, mysql is preserving backwards compatibility? Good. A flag to break this backwards compatibility and offer a larger range is probably warranted, but until that&#x27;s implemented this behavior is fine.<p>&quot;I think this is stupid&quot; is a really poor reason to break backwards compatibility, despite how many other software projects use this reasoning.<p>But of course, MySQL bad, PostgreSQL good.
评论 #24699332 未加载
评论 #24705955 未加载
hackbinary超过 4 年前
I learned the semi hard way on PoC system where the Mysql index corrupted.<p>I was lucky and could simply redeploy my application, but I have never used Mysql since.
评论 #24699572 未加载
jspaetzel超过 4 年前
How&#x27;d this get voted so many points? RTFM and use a more appropriate datatype.