<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'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't look at all those If statements crowding around your code base and think "this is confusing, I should work out a way of consolidating all these If statements". Don't worry about the Select statements either, for the same reason.</p>
<p>Become more comfortable with SQL. It'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>
