What is the idiomatic way to consolidate sql queries in golang?

blov · · 188 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>I am working on a project that is growing in terms of the amount of people working on it and the amount of different queries we have to support. It seems people are just writing more and more separate queries. Although I am only a junior developer, I can foresee this becoming hard to maintain. What is usually the idiomatic way of consolidating sql queries in golang. And do you consolidate by feature or by table?</p> <hr/>**评论:**<br/><br/>MadPhoenix: <pre><p>I understand the inclination to think of SQL queries like code that can benefit from being refactored into a generic form that works everywhere, but in order to get good performance with SQL you should think of your queries like specialized tools for a specific job. For a particular query you want to request just what you need with as few conditions on it as possible in order to get the job done. Consolidation would infer that you&#39;ll wind up requesting more data than you really need with more conditions that you probably need to consider for a particular purpose. That is a path towards painfully slow, difficult to debug application performance.</p></pre>dazzford: <pre><p>Keep the query close to the code which uses it, ideally within the same function, but at least within the same file.</p></pre>gentleman_tech: <pre><p>SQL is code. It lives in your code base.</p> <p>You wouldn&#39;t look at all those If statements crowding around your code base and think &#34;this is confusing, I should work out a way of consolidating all these If statements&#34;. Don&#39;t worry about the Select statements either, for the same reason.</p> <p>Become more comfortable with SQL. It&#39;s survived this long for very good reasons.</p></pre>goomba_gibbon: <pre><p>What do you mean by consolidate? I suppose the goal is to allow re-use of large parts of queries and reduce repetition in the code.</p> <p>Do you have an example? Even an artificial one might help.</p> <p>In general Go favours being verbose but still easy to understand.</p></pre>aboukirev: <pre><p>Practically never by table. I usually split data access code into modules that access relatively independent set of tables. That way I can search on a column name in a single file and make changes consistently if situation requires it.</p> <p>There may be some queries that span these sets/groups. Those go into one of the sets or into a separate file. Nothing is perfect. The worst case scenario is to check two files for potentially needed modifications.</p> <p>In SQL I always use column name delimiters (square brackets in MS SQL, double quotes in Postgres, backticks in MySQL) so that I can lookup column and not variable or other identifier by the same name.</p> <p>This is just basic hygiene when working with SQL queries embedded in the code.</p> <p>As usual, YMMV.</p></pre>amorphatist: <pre><p>H</p></pre>TrueFurby: <pre><p>i</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

188 次点击  
加入收藏 微博
0 回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传