|
The solution to your problem with storage, retrieval and categorizations is obvious:
Put them into a database.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos, GHB wrote: Put them into a database.
well i have them in excel so ive already done that.😄
|
|
|
|
|
|
"This is the way."
~Mandalorian
probably best way for me too
|
|
|
|
|
MSSQL snippets works perfectly for me except you need to rabbit through the category folders to find the exact one you need  . Tis a bitch when you can't remember the category/folder it lives in.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Quote: There is no good way to store good SQL queries for future use.
What's wrong with stored procedures?
|
|
|
|
|
Member 13301679 wrote: What's wrong with stored procedures?
I mean like a development studio type of thing where you can select a particular SQL statement that you want to run manually when you're examining data and designing queries.
We use SPs for all interactions with DB but I'm talking more about a code reuse type of thing.
I guess I could create a library of SPs and then run those when I need to, but I'd still need a way to manage them with names and stuff so I could remember what they do.
I guess it is really because I'm in the midst of designing queries for a large system and I only have to do this every 2 or 3 years so I have a long time away from it.
|
|
|
|
|
Quote: I mean like a development studio type of thing where you can select a particular SQL statement that you want to run manually when you're examining data and designing queries.
MySQL Workbench allows that, including loading and saving the files just like an IDE, keeping files in different tabs, etc.
|
|
|
|
|
Looks interesting. I'm checking that one out. Looks similar to SSMS (Sql Server Mgmnt Studio)
|
|
|
|
|
|
That does look good but...
Link provided said Important
This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
|
|
|
|
|
|
|
A lot of tools come to mind on this topic.
Notepad, or Notepad++:
I recommend using "AGENT RANSACK" a very fast multi-threaded Search engine.
(You can start the search in your ROOT file for the SQL files)
(Side note: This is my number one favorite tool)
Organize the SQL files, by INDEXING Them (aka: "Tags")
INDEX: (Example)
#DATE Ex: 01/01/2021
#PROJECT Ex: (NAME)
#TYPE Ex: (SELECT INSERT UPDATE DELETE)
#NOTATION Ex: That query for the thing I had to do at 1AM
...more as needed
----------------------------------------------------------------
<SQL HERE>
Open "Agent ransack" and search on terms in the sql.
This could be all put in a database, but I think that may be a bit too much.
You want something simple, and you want to find it fast.
You already have a body of SQL that is not indexed.
Start indexing all NEW SQL FILES, and as you revisit the old ones, (that are not indexed),
Index them as you go along.
Keep it all in one file, or multiple files, doesnt matter much with Agent Ransack.
So what you wind up with is your very own Google Search for your sql.
Keep It Simple, keep it moving.
|
|
|
|
|
Interesting. I shall consider it.
|
|
|
|
|
A side benefit - I think you will really like Agent Ransack - as a bonus.
I have used this tool for years. Its the one tool I cannot live without.
You know you got the queries.. you just need help finding them.
Comment them over time. Comment new ones when you make them.
Then let Agent ransack do the work.
Keep It Simple, keep it moving.
|
|
|
|
|
I would suggest a couple of things:
- a stored procedure that is just a collection of these wonderful SQL statements that is commented well and set up to NOT be runnable (comment out the whole thing between /* and */, probably)
- set up a comment area above each piece of code with keywords or details about what the code does and what it would be useful for
- using a search (CTRL-F) on the stored procedure you called GreatCodeToMaybeReuseSomeday (or whatever) to find the SQL of interest.
- Copy and paste the code you found.
Probably the closest to "think it and it will appear"
|
|
|
|
|
Just a thought: Use a library like JsonQL to convert SQL to a JSON representation and store them in MongoDB with descriptive metadata. Search on the content and/or metadata.
|
|
|
|
|
This one gets my "programmer's mind" thinking about a lot of possibilities.
|
|
|
|
|
I find it handy to store them as pass-through queries in an MS Access database. You can give them names that work for you, and then sort them, filter them, search for them, etc. I also wrote a VBA function to let me search for any text string in all my Access queries in case I want to find which ones contain a certain table or field name and so on.
|
|
|
|
|
This sounds like an interesting solution. I figured someone out there must be doing things like this. 
|
|
|
|
|
For very special, or big, or being used a lot, queries (or for clients who can't spell SQL  ), I use something that you will probably hate. I use Java 
I make a program in Java (basically a custom SQL generator) where I insert the code inside a method that receives parameters that allow to configure the query in things like database/table/field names, which fields to return, insert sub-queries, etc. Then document with Javadoc as with any other program.
All the queries are inside the same Java program, are selectable and configurable via command line or a web page that dynamically requests more configuration based on what you requested and configured so far.
Using the generated Javadoc or an IDE on the program source makes it easy to find anything. The program makes easy to get the configured SQL.
This has the advantage that you can tweak the Java source to add more functionality to the queries and make that selectable via parameters. You can even pass the program to clients and they will happily build some queries they need by just answering configuration questions and never touching SQL.
I have done this for a client in the past in which the program would generate SQL and JavaScript (to interact with the SQL via web page) for their web site recommendation system using Similarity Matrices, Friends-of-Friends and a few other algorithms implemented in SQL.
Since their recommendation system used the same algorithms to recommend different things (people, items, lists of people-item pairs, etc), this method was easier for me to maintain and they were very happy to be able to generate the required SQL in less than 5 minutes by answering a few questions instead of manually modifying each time the almost 500 lines of SQL code for the Similarity Matrix alone. They were even able to use the program by themselves, without requesting my help, to generate SQL to recommend things that were never mentioned to me.
Unfortunately, I can not show any of those programs as they are protected by IP 
Yes, this is convoluted, but makes things easier on the long run.
|
|
|
|
|
I don't hate Java, actually. I really like Java as a language. Also, this sounds like the kind of thing that I was thinking might be going on out there -- custom solutions that help you design sql queries and manage them(for devs).
|
|
|
|
|
I meant that you would hate the methodology of writing SQL using another language, not the language itself, since it is more work initially. You have to break the SQL code into pieces to insert variables in between, write the program code and document it.
Most of the times I mention this methodology people look at me as if I just told them to program everything in assembly!
I use Java for this since it is very easy to convert to a servlet and have the interface on a web page, although I prefer to use the command line. My knowledge of web technologies is limited and all my pages end up looking like 
|
|
|
|
|
My company uses SourceGear Vault Standard to store tables, stored procs, functions and queries, but I keep a folder of SQL named with a date and purpose. An example would be '20201201_RestoreDataForCustomer'. The date gives me a context to find them more quickly.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
