Eu quis falar sobre isso pois eu vejo muitas dúvidas e uma falta de direção de pessoas que estão começando em TI ou pensando em trocar de carreira. A resposta rápida para a pergunta “eu preciso saber SQL para conseguir um trabalho na área de dados?”, é sim, precisa. Nos próximos parágrafos eu te explico por que eu penso isso.
É fácil se perder no meio de tantas linguagens de programação e metodologias de projeto que às vezes o básico fica pra trás. Eu acredito que ter uma boa fundação pode te abrir portas que antes você não veria. Eu tenho certeza que SQL é uma grande skill pra se ter na área de dados.
Os data jobs estão em alta há alguns anos. Existe muita especulação sobre o que uma pessoa da área faz (e realmente, isso pode variar muito). Porém, existe uma habilidade que sempre aparece nas descrições de vagas de trabalho. Você consegue encontrá-la abaixo nos exemplos?
Linkedin, Julho 2021
Linkedin, Julho 2021Linkedin, Julho 2021
O SQL sempre está em demanda para muitas vagas. Porque faz parte dos básicos da área. Quando você domina os básicos, você tem grandes chances de prosperar. Você pode aprender coisas ótimas sobre a área de dados, mas no fim, em algum momento você vai precisar lidar com ele: um banco de dados. E adivinha: SQL é justamente como nos comunicamos com os bancos de dados, sua própria língua (eu acho isso lindo, pare de me julgar!).
Eu estou trabalhando em uma série de posts dedicados à pessoas que gostariam de aprender SQL do zero. Meu foco será o produto da Microsoft, o MS SQL Server. Eles tem uma “versão” de SQL só para esse banco de dados, é o T-SQL. Eu espero compartilhar meu conhecimento com você e quem sabe eu não ajude alguém no meio do caminho. Esse é meu jeito de retribuir para a comunidade 🙂
Perguntas ou sugestões, meus comentários estão sempre abertos!
Se você quiser ler este mesmo post em inglês, leia aqui.
I wanted to talk about this because I see a lot of doubts and lack of direction from people who are either beginning now in IT land or thinking about switching careers. The short answer to “do I need to know SQL for a data job?” , is yes. In the next few paragraphs I explain why I think so.
It’s easy to get caught up in all the fancy programming languages and methodologies for projects that sometimes the basics… are just not there. I believe having a good foundation opens paths to other doors that you could not see before. And I’m certain that SQL is one hell of a foundation to have in the data land.
Data jobs have been on a hype for the past few years. There’s a lot of speculating about what a data person job is (and actually it can vary a lot). However, there is one skill that seems to endlessly haunt job descriptions. Can you spot it below?
Taken from Linkedin, July 2021Taken from Linkedin, July 2021Taken from Linkedin, July 2021
SQL is always on high demand for any data job. Because it’s part of our basics. And knowing your basics can help you thrive. You can learn a lot of interesting stuff about data, but in the end, you’ll most likely need to get your hands on a database at some point, and SQL is how you talk to a database (and I think that’s beautiful. Stop judging me!).
I’m working on a series of posts dedicated to people who would like to learn SQL from zero. I’ll focus on the Microsoft product, MS SQL Server. They have a version of SQL just for it, it’s called T-SQL. I hope to share my knowledge with you and perhaps help someone along the way. This is my way of giving back to the community 🙂
Any questions or suggestions, my comments are always there for you.
If you want to check out this same post in Portuguese, click here.
Convite para evento online: Women Techmakers Montreal
Olá! O post de hoje é um convite ao evento: Women Techmakers Montreal.
Women Techmakers é um programa criado pelo Google, para celebrar o Dia Internacional da Mulher e para realçar o talento das mulheres em tecnologia. Este programa já passou por mais de 200 eventos globais e 52 países. O próximo evento será no sábado, dia 20 de Março, 2021.
Ano passado, eu me lembro de estar muito animada para participar do evento em Montreal. Porém… o COVID aconteceu e eventos foram cancelados. Felizmente, a organização mudou para um evento online. Foi um dia maravilhoso! Cheio de mulheres super inspiradoras e uma comunidade linda.
Esse ano, eu quis: 1- fazer com que mais pessoas descubram o evento, e 2- fazer com que mais pessoas participem!
Quem pode participar?
Todos os gêneros são bem vindos! Se você gosta de tecnologia, eu tenho certeza que você encontrará um tópico que te interessa. Se inscreva e aproveite! (:
Importante: por ser realizado em Montreal, todo o conteúdo será em inglês ou francês.
O evento é de graça e dura o dia todo (das 9AM às 6PM EST). Aqui você pode consultar a agenda do dia.
Caso você queira ver o que rolou no ano passado, aqui está uma playlist com as sessões.
Invitation to join online event: Women Techmakers Montreal!
Hello everyone! Today’s post is an invitation to the Women Techmakers Montreal event.
Women Techmakers is a program created by Google to celebrate International Women’s Day and to highlight the talent of women in technology. This program has been in over 200 global events and seen across 52 countries. The next event will be on Saturday, March 20, 2021.
Last year, I remember being really excited to go to the event in Montreal, when COVID hit and events all over were cancelled. Luckily, the organization switched to an online event instead. It was an amazing day! Full of such inspiring women, and such a beautiful community.
This year, I wanted to: 1- let more people know about the event, and 2- get people to join the event!
Who can join?
All genders are welcome! If you’re into tech, I’m positive you’ll find a topic that will get your attention. Sign up and enjoy (:
The event is totally free and lasts the whole day (from 9AM to 6PM EST). Check out their amazing agenda.
If you’re wondering about what happened last year, check this playlist with their sessions.
Eu escrevi esse post em duas versões. Esta que você está lendo em português, e uma em inglês.
Se você trabalha com dados, você provavelmente não tem controle sobre todas suas fontes. Por exemplo, você pode coletar dados de lugares diferentes. Talvez seja o seu trabalho centralizar os dados, e criar padrões para que os dados façam sentido para o seu time. Uma vez que você entendeu seus dados, você pode extrair o real valor deles.
Quando seus dados existem em diferentes sistemas, talvez você não tenha controle sobre a validação que acontece por trás.
Por exemplo, um dos seus fornecedores podem ser muito específicos sobre os tipos de dados que eles permitem no sistema. Isso significa que quando os dados chegarem até você, você verá algo (idealmente) mais estruturado. Contudo, seus dados podem também prover de um sistema liderado por desenvolvedores que decidiram deixar o usuário “livre” para fazer o que quiser (atenção ao verbo “querer” e não “precisar”, existe uma grande diferença aí).
Dados dos tipos de datas são muito importantes em SQL. Mas para nós humanos, datas podem ser formatadas de diferentes maneiras… Por exemplo, no Brasil, escrevemos datas de um jeito diferente dos Estados Unidos.
Brasil: DD/MM/AAAA
EUA: MM/DD/AAAA
Em SQL, seu tipo de data é guardado no banco assim: AAAA-MM-DD. Não tem como errar, certo? Errado.
Lembra quando eu disse que você pode ter origens diferentes dos dados e que por isso não tem controle sobre as validações? Vamos pensar no seguinte exemplo:
Seus clientes usam um sistema de outro fornecedor, passando os dados para eles
O fornecedor usa os dados para fazer o que quer que seja que o sistema faça
Eles te enviam os dados com o resultado do projeto
Você, um profissional inteligente, tenta carregar os dados no seu sistema. E mais importante, seu sistema é formatado com os tipos de dados que você espera receber. Então, digamos que você queira receber um campo com valores do tipo data, você vai formatar sua tabela para ter um tipo de data.
Vamos usar a tabela “ThirdPartyInfo” abaixo como exemplo.
Agora, como você já deve ter imaginado, seu fornecedor não aplicou nenhum tipo de validação para esses tipos de dados. Logo, você pode se deparar com alguns tipos de datas estranhos, como esses:
Jan/2021
03-20-18
01-02-03 (onde começar com esse?!)
2022/2
Entre outros…
Isso é o que acontece quando tentamos inserir algo que não é uma data, em qualquer uma das colunas do tipo data.
Não importa o método que você use para popularizar essa tabela, você vai receber um erro se você não está passando valores do tipo data para suas colunas do tipo data.
Como evitar problemas como esse
Seja honesto com o seu fornecedor sobre a razão de ter os tipos de dados que você precisa, e explique quais são eles. Como explicar? Fazendo aquilo que os profissionais de TI mais odeiam: documentando.
Se o fornecedor está relutante com a mudança, fale com seus superiores, mostre para eles cenários onde você tem que gastar seu tempo precioso (e caro) só para arrumar esse erro. Reinforce que isso pode ser evitado se todo mundo estivesse na mesma página sobre os tipos dos dados que vocês compartilham.
Se nada acima funcionar, ou você precisar de uma solução temporária enquanto a situação se resolve, você poderia validar os dados do seu lado. Se você fizer um esforço agora, antes do problema, pode parecer mais trabalho, massss o você do futuro vai te agradecer por ter se esforçado antes do problema chegar.
Aprendendo do pior jeito
Exemplo da vida real: eu recentemente tive um problema que me custou um certo tempo. Eu recebi um arquivo csv necessário para um relatório, e o arquivo tinha alguns campos de datas. Minha tabela estava esperando receber os campos de datas com valores…de datas. Porém, meu job do carregamento dos dados estava com problemas.
Eu tive que dar um passo para trás e tentar encontrar a raiz do problema. Eu pensei que fosse ser algo fácil de conseguir se eu olhasse as entradas mais recentes do arquivo (esse tipo de arquivo era mandado pra nós todos os dias, com as coisas mais recentes atualizadas). Meu problema principal, foi que eu não isolei a coluna de data que estava dando erro. Na verdade, no SQL Server, a mensagem de erro quase sempre é muito genérica, e não me falava qual a coluna. Tudo que eu sabia era que uma string estava tentando ser convertida em data, mas sem sucesso.
Meu segundo maior problema foi arrumar tudo que eu encontrei no arquivo, que pudesse de alguma forma estar causando o problema. Alerta spoiler: isso não resolveu meu problema.
Eu demorei um tempo para entender que usar a função “ISDATE”, seria uma maneira fácil de procurar por uma coluna que esperava receber um tipo de data, mas que recebia outra coisa.
Em momentos de desespero, esquecemos soluções simples, como esta.
Observe que o resultado dessa consulta tem um valor do tipo texto. Agora, você pode aplicar essa validação ANTES de carregar os dados na sua tabela de produção, além de usar o mesmo comando para investigar problemas como esse.
Resumindo: eu na verdade gosto do tipo DATE no SQL. Funciona bem, mas o problema real foi que falhamos como humanidade pois nunca concordamos em um único formato para datas. Espero te ajudar de alguma forma!
Se quiser ler mais sobre tipos de dados de datas em SQL, leia aqui (em inglês).
Você resolveria meu problema de uma maneira diferente? Me conte abaixo nos comentários (:
I wrote two versions of this post. This one you’re reading in English, and this one in Portuguese.
If you work with data, you probably do not have control over all the data sources you need. What I mean, is that for example, you may receive data from different places. Perhaps it’s your job to centralize and standardize it the best you can, so that it makes sense to your team. Once you understand the data, value can be extracted from it.
When your data comes from different systems, it’s likely you will not have control over the data’s validation. For example, one of you vendors may be very specific about the data types allowed into their systems, which means when the data gets to you, you’ll see something (ideally) more structured. However, your data may also be handled by a group of fed up developers who decided they will allow everything the user wants (special attention to the the verb there being want instead of need, big difference).
Date data types are really important and used in SQL. But for humans, dates can be formatted in some ways… For example, I’m from Brazil, and the way we write our dates is different from the US.
Brazil: DD/MM/YYYY
US: MM/DD/YYYY
In SQL, your date type stores data like this: YYYY-MM-DD. No room for mistakes, right? Bam, Wrong.
Remember when I said you may have different data sources and you can’t control their data type validations? Let’s think of the following example:
Your clients use a 3rd part system
The 3rd party uses the data to do whatever it is their system does
They send you that data with the results of your project
You, a smart data person, tries to load the data into your system. Most importantly, your system is formatted with the data types you expect to receive. So, for example, if you expect a field with a date value, you’ll format your table to have a date type column.
Let’s use the table “ThirdPartyInfo” as an example.
Now, as should have assumed by now, your third party did not applied any data validation to the date types. Hence, you may get some crazy “dates”, like this:
Jan/2021
03-20-18
01-02-03 (where to even begin with this one?!)
2022/2
and many others….
Here’s what happens when you try to insert something that’s not a date, into any of the date columns:
It does not matter the method you’ll use to input data to your table, you’ll get an error if you’re not passing date values to your date types columns.
How can you avoid issues like this
Be open to your vendor about why this is important to your data, and explain to them your tables data type. How? Documenting, the thing IT people hate most.
If the vendor is pushing back, talk to your superiors, and show them a scenario in which you need to spend your precious (expensive) time to fix this mishap. Enforce this could be avoided if everyone were on the page about the data types for the data you share.
If nothing above works, or you need a temporary solution, you could validate the data on your end too. More work upfront, but your future self will thank you for putting this effort now.
Learning it the hard way
Real life example: I recently had an issue that cost me a lot of time. I had received a csv I needed for reporting, and the file had a few date fields. My table, was expecting date types to come in all the fields, but I was getting errors on my data loading job.
I had to take a step back and find where the issue was. I thought it would be easy to find, by checking the most recent info that got into the system (this was a daily file we received), and so I started looking for the issue. My main mistake, was that I did not isolate the date column that was giving me an error. In the SQL Server, the error message was really vague, I could only tell there was a string trying to be converted to date and I had several different date fields in my table.
My second big mistakewas fixing everything I found on the source file, and I thought was wrong and causing the issues.Spoiler alert: it wasn’t.
It took me some time to realize that “ISDATE” was an easy way to search for a column that is expecting a date type, but received something else instead:
In desperate times, we may be blind by stress and not think about simple things, like this.
You see that the return to that query has the string value. Now, you could apply this kind of check as a validation before you load data into your production table, and also use it to troubleshoot issues like mine.
With all that being said, I actually like the DATE data type in SQL. It works great, the real issue is that we as humanity never agreed on a single date format. Sigh. I hope this helps!
If you want you can read more about the Date types here: Date types in SQL
Would you solve my problem in a different way? Tell me how below in the comments (:
Eu adoro me manter informada através de blogs e podcasts. Sempre me inscrevo em diferentes sites, blogs e comunidades por aí. Quando não estou afim de ler e procuro uma coisa mais descontraída ou quero conhecer outros profissionais, eu escuto podcasts. Acredito que esses sejam jeitos fáceis e legais de me manter informada sobre novidades e o que está rolando na comunidade.
Além disso, os sites e podcasts me permitem aprender sobre coisas que talvez eu nunca procuraria. Pensando nisso, eu resolvi dar dicas de alguns sites e podcast que eu sigo e indico. Pequeno lembrete: eu trabalho na área de dados, então a maioria das minhas dicas serão relacionadas a área.
NerdTech, episódios sobre tecnologia do podcast Nerdcast
Inglês
Caso você saiba falar inglês e queira praticar, aqui estão meus blogs preferidos:
Brent Ozar, Microsoft Certified Masters, Brent trabalha como consultor e tem varios treinamentos de SQL Server, blog e canal no youtube (ps: os treinamentos dele são fantásticos, indico muito!)
I want to talk about communication, mostly focusing on what we, geek souls, do as common mistakes and what we can do to improve it.
Personally, I’ve always tried to make an extra effort to communicate as clearly as possible. And that is a rule I live by, specially when I talk to non-tech people. What I mean by that are managers, scrum masters, project stakeholders and clients for example. We need to know that when we’re talking to someone, and that person is not from an IT area (or maybe even is!), they may simply not know the terms we are used to.
When you try to sound fancy talking about your job, about how you solved or stopped something from happening the other day, you may feel a need to drop-in some technical terms…perhaps you should ignore that need.
Truth is that you will sound like someone who has no empathy to their listener.
Eventually, your colleague may even ignore talking to you because they just don’t get what you say. Ouch.
Imagine you know nothing about cooking, and then you go ask a chef for a recipe, and they talk about all different kinds of kitchen utensils and cooking techniques, using all kinds of French names and other stuff you have no idea about. Would you like that kind of approach? Wouldn’t it be better, if the chef explained it to you in an easier way? Gosh, you just wanted to have dinner.
So whenever you feel like taking a shortcut and use all the terms you do on your job, take simpler steps. Describe them, explain what they are, use common terms, and most importantly – show examples.
Once you remember this rules, your communication should flow more naturally, and people will want to talk to you because now they get it!
Where can you apply all this?
Everywhere. In person/online meetings, emails, blog posts, events. There’s no limit, go for it.
Take a few extra moments to actually explain the process. Always give the person the context behind what you’re talking and they’ll most likely understand it. Don’t get too attached to some terms. You may be even repeating the same thing without realizing it, because you’re not listening to yourself.
For example, let’s say you’re running out of space on your server’s disk drive, due to the size of your backup files. You need to bring in your manager to discuss your options, which may include budget wise decisions.
Start by giving them context. Explain what are the backups. Explain WHY you need to take backups. And win they heart by scaring them off with “here’s what happens if we lose the files for a week”. Show them a screenshot of how much disk space you’ve used vs how much you’ve got left. Bring them the info of how often you clean the folders and zip files, and approximately how much time you spend on that. Once you lay the ground, they will see how relevant that is, and why you need their money support.
That’s what works for me. Looking at if from a slightly different communication tool, I love it when someone is having an issue and they send me an email with all the information I need upfront. A beautiful email would contain things like:
what happened
when it happened
what’s the suspected root cause
what happens if this is not fixed within x hours/days/weeks
who uses it
and if they’re an angel they may even give me a suggested fix (mostly within IT teams)
they avoid using really specific terms and describe things instead
they avoid using internal terms that others from outside the team may not know
That makes my life easier. I don’t need to be going back and forth about the issue, because just with that one email, I have enough to *at least* start investigating. Honestly, by being proactive about that email, the person just saved ourselves a chunk of time and our inboxes some space. There is nothing more frustrating than going back and forth trying to understand what happened and the other person is just trying to scape from your questions.
There are many other tips about this topic, so I’ll bring it again. In the meantime, what’s something you do that makes your life easier when communicating with non-techs? Share it on the comments below 🙂
Would you like to read this post in Portuguese? Click here.
Hoje eu vou falar sobre comunicação, com foco no que nós, geeks, cometemos como erros e como podemos melhorar.
Pessoalmente, eu sempre tentei fazer um esforço para me comunicar do modo mais claro possível. Isso é uma regra interna para mim. Especialmente quando eu estou falando com pessoas que não são da área de TI. Como por exemplo, gerentes pessoais, gerentes de projetos, scrum masters, parceiros e clientes, por exemplo. Nós precisamos saber que enquanto estamos falando com alguém, e a pessoa não é da nossa área (ou às vezes até podem ser!), eles podem simplesmente não conhecer os mesmos termos aos quais estamos acostumados.
Quando você tenta parecer espertinho ou espertinha falando do seu trabalho, sobre como foi incrível resolvido aquele problema no outro dia, você talvez sinta uma coceirinha de vontade de jogar uns termos técnicos na conversa…talvez você devesse ignorar essa necessidade.
Na verdade, você só vai aparecer alguém que não tem empatia com o seu ouvinte.
Eventualmente, seu colega pode começar a evitar falar com você pelo fato de não te entender. Essa doeu.
Imagine que você não sabe nada sobre cozinhar (exemplos meramente ilustrativos, ok?). Então você decide pedir uma receita a uma chef de cozinha, e ela te ajuda, mas falando de vários utensílios que você nem conhece, técnicas que você nunca ouviu falar, usando nomes franceses que você não tem ideia nenhuma se são comida ou um xingamento. Você gostaria de ser ajudado assim? Não seria melhor, se a chef te explicasse de uma maneira mais simples? Você só queria jantar, sabe…
“Por que voce não me explica como se eu tivesse 5 anos?”
Então, quando você pensar em pegar o atalho cheio de termos complexos do seu trabalho, talvez dê passos mais simples. Descreva o que está acontecendo, explique o problema, use termos mais conhecidos, e mais importante – mostre exemplos.
Uma vez que você lembrar dessas “regras”, a sua comunicação deve fluir mais naturalmente, e as pessoas vão querer falar com você pois afinal agora eles te entendem!
Onde isto pode ser aplicado?
Todos os lugares e momentos. Reuniões em pessoa e online, posts de blogs, eventos. Não há limites.
Use uns momentos a mais pra realmente explicar os processos. Sempre de o contexto por trás do que você está falando e será mais fácil te entenderem. Não se apegue aos termos. Às vezes você pode até estar repetindo coisas sem perceber, por que você não está prestando atenção na sua fala.
Por exemplo, digamos que você está com pouco espaço no seu servidor, devido ao crescente tamanho dos seus arquivos de backup. Então, você precisa falar com um gerente para discutir opções, que podem incluir decisões que envolvem o orçamento.
Comece explicando o contexto. Fale sobre o que são os backups. Explique por que você precisa deles. E finalmente, ganhe seu gerente com um belo susto mostrando o problemão que você tem se perder os arquivos por uma semana. Mostre um screenshot de quanto espaço você tem vs o quanto está livre. Leve a informação de frequência com qual as pastas são “limpas”, e quanto tempo é gasto nisso. Uma vez que você tenha estabelecido esse terreno, eles vão entender o quão relevante isso é pra você, e por que você precisa do DINHEIRO suporte.
Isso é o que funciona pra mim. Pensando em uma forma um pouco diferente de se comunicar, eu AMO quando alguém tem um problema, e me mandam um email com toda a informação de antemão. Um email lindo desses geralmente possui o seguinte:
o que aconteceu
quando aconteceu
qual a suspeita de problema
o que acontece se isso não for consertado em x horas/dias/semanas
quem foi impactado
e se eles forem um anjo divino eles ate incluem uma sugestão de como resolver o problema (mais comum sendo um outro time de TI)
eles evitam usar termos muito específicos e descrevem mais
eles evitam usar termos internos que não fazem sentido para outros times
Isso tudo facilita a vida. Eu não preciso ficar escrevendo vários emails, por que logo de uma vez eu tenho o mínimo pra poder começar investigar. Honestamente, sendo proativa no email, a pessoa nos salvou um tempinho e espaço na inbox. Não há nada mais frustrante que tentar pescar informações e a pessoa fugir das perguntas respondendo o mínimo do mínimo.
Existem várias outras coisas que eu gostaria de falar sobre esse tópico, então provavelmente ele voltará. Enquanto isso, o que você faz pra se comunicar com leigos que deixa sua vida mais fácil? Comenta aí embaixo!
Quer praticar seu inglês? Leia o post em inglês aqui.
Conhece o sentimento de abrir um novo arquivo, e pensar “eu não vou reutilizar esse código… só vou fazer isso uma vez…”. Nós dois sabemos que você está mentindo.
Eu estou falando isso pois, na maior parte do tempo:
seu código é reutilizável
você é humano e esquece as coisas. Então, talvez amanhã você já tenha esquecido como resolver uma coisa que você fez hoje.
eu nunca vi onde você salva seus scripts mas eu aposto que você poderia fazer uma boa limpeza na sua pasta
Quando você está trabalhando em algo, tente se imaginar no futuro. O seu “eu” mais velho provavelmente não tem ideia do que seja o *projeto_importante_2018_script*. O seu eu mais experiente está feliz lendo este arquivo? Eu acho que não.
Se você fizer um esforço agora para ser mais “arrumadinho” com o seu código, essas pessoas vão ficar muito felizes:
o seu eu futuro
seus colegas de trabalho que leem seus códigos
pessoas que vão assumir seu lugar no futuro, e vão pensar “olha só! essa pessoa não era tão péssima, era apenas ruim mesmo!”
Como adicionar comentários em SQL
Basicamente, existem duas maneiras de adicionar comentários em SQL:
1- adicione “–” e comece a digitar!
2- adicione “/**/” e escreva entre os asteriscos.
Nenhum é melhor que o outro. A primeira opção é mais usada para comentários na mesma linha do código. A segunda, é mais comum para comentar blocos de código, ou escrever comentários maiores que não vão ficar em uma linha gigante.
Comentários iniciais
Pessoalmente, eu acredito que comentários são algo bom. não é algo que eu faça em cada linha do código, porem, quando eu abro uma nova query, automaticamente eu adiciono um cabeçalho de comentários.
Eu começo meus scripts da seguinte forma:
Autor: quem está escrevendo o script.
Data: quando o script foi criado, para edições eu geralmente adiciono um edit na mesma linha.
Projeto: qual projeto o script faz parte. É legal descrever um pouco o projeto.
Descrição: descrever a razão do seu script, aqui é onde você explica onde está parte se encaixa no todo.
Requisitado por: nome de quem pediu que isso fosse desenvolvido. Além dos nomes, talvez seja interessante adicionar também os emails para contato.
Importante: se você está escrevendo uma stored procedure, lembre-se de adicionar o seu bloco de comentários depois do comando “CREATE PROCEDURE”. Fazendo isso, o seu comentário vai estar integrado ao código da proc, e vai aparecer inclusive quando você escolher a opção de “modificar” o arquivo. Se você não fizer assim, o comentário vai ficar salvo apenas no próprio arquivo principal do script.
Dando um nome ao arquivo
Tente ser descritivo e intuitivo quando for nomear seu arquivo, e não abrevie muito. O nome que você escolheu pode parecer relevante na hora, mas de novo, pergunte-se se o seu eu do futuro está te odiando agora.
Se o seu script fizer parte de um projeto maior, então tente começar o nome do arquivo como algo que remeta ao projeto.
Por exemplo: sp_RelatorioFinancasAutomatico_CalculoSalarioFuncionario
Com esse nome, sabemos:
sp: isso é uma stored procedure
RelatorioFinancasAutomatico: nome descritivo do projeto
CalculoSalarioFuncionario: o que a sua parte especifica do script faz
Evite usar termos como “novo”, “velho”, “final”, dentre outros. Isso não é útil em longo prazo. Se você está criando vários rascunhos, por exemplo, seria interessante versionar, usando “v1”, “v2”, ou até adicionar a data no nome do arquivo. Mas, lembre-se que esses nomes deveriam ser temporários, e assim que você descobrir qual finalmente é sua versão “v23_final_novo”, mude esse nome. Outra coisa que você pode fazer é mover seus rascunhos para uma sub-pasta dentro do projeto, assim fica mais fácil de organizar os scripts “finais” e importantes.
Essas são coisas básicas que eu faço todos os dias. Espero que você tenha achado útil. Existe outra coisa que você adiciona que gostaria de compartilhar? Deixe seu comentário (:
Camila Henrique 