From 8b9bea731164ffe85a1dee0dbbf3d12b39dfc586 Mon Sep 17 00:00:00 2001 From: Unknown Date: Sun, 16 Apr 2017 20:21:38 -0300 Subject: [PATCH 01/29] Translating Overview - Translation for the overview section. --- _includes/sqlstyle.guide.pt-br.md | 1287 +++++++++++++++++++++++++++++ 1 file changed, 1287 insertions(+) create mode 100644 _includes/sqlstyle.guide.pt-br.md diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md new file mode 100644 index 0000000..3540c92 --- /dev/null +++ b/_includes/sqlstyle.guide.pt-br.md @@ -0,0 +1,1287 @@ +# Guia de Estilo SQL + +## Visão Geral + +Você pode utilizar esse conjunto de diretrizes, [fazer um fork][fork] ou criar +seu próprio - a chave é que você selecione um estilo e o siga. Para sugerir +alterações ou correções de bugs, por favor abra uma [issue][issue] ou faça um +[pull request][pull] no GitHub. + +Essas diretrizes são desenhadas para serem compatíveis com o livro +[SQL Programming Style][celko] de Joe Celko, para ser adotado por times que já +leram o livro mais facilmente. Esse guia é um pouco mais opiniativo em algumas +áreas, enquanto em outras, é mais relaxado. É certamente mais sucinto que +[o livro de Celko][celko], já que ele contém anedotas e racicínios por trás de +cada regra para reflexão. + +É fácil incluir esse guia com o [formato Markdown][dl-md] como parte do código +base de um projeto, ou referenciá-lo aqui para que qualquer um no projeto possa +ler livremente - muito mais dificil com um livro físico. + +O Guia De Estilo SQL por [Simon Holywell][simon] é licenciaso sob a +[Creative Commons Attribution-ShareAlike 4.0 International License][licence]. +Baseado no trabalho em [http://www.sqlstyle.guide][sqlstyleguide]. + +## General + +### Do + +* Use consistent and descriptive identifiers and names. +* Make judicious use of white space and indentation to make code easier to read. +* Store [ISO-8601][iso-8601] compliant time and date information + (`YYYY-MM-DD HH:MM:SS.SSSSS`). +* Try to use only standard SQL functions instead of vendor specific functions for + reasons of portability. +* Keep code succinct and devoid of redundant SQL—such as unnecessary quoting or + parentheses or `WHERE` clauses that can otherwise be derived. +* Include comments in SQL code where necessary. Use the C style opening `/*` and + closing `*/` where possible otherwise precede comments with `--` and finish + them with a new line. + +```sql +SELECT file_hash -- stored ssdeep hash + FROM file_system + WHERE file_name = '.vimrc'; +``` +```sql +/* Updating the file record after writing to the file */ +UPDATE file_system + SET file_modified_date = '1980-02-22 13:19:01.00000', + file_size = 209732 + WHERE file_name = '.vimrc'; +``` + +### Avoid + +* CamelCase—it is difficult to scan quickly. +* Descriptive prefixes or Hungarian notation such as `sp_` or `tbl`. +* Plurals—use the more natural collective term where possible instead. For example + `staff` instead of `employees` or `people` instead of `individuals`. +* Quoted identifiers—if you must use them then stick to SQL92 double quotes for + portability (you may need to configure your SQL server to support this depending + on vendor). +* Object oriented design principles should not be applied to SQL or database + structures. + +## Naming conventions + +### General + +* Ensure the name is unique and does not exist as a + [reserved keyword][reserved-keywords]. +* Keep the length to a maximum of 30 bytes—in practice this is 30 characters + unless you are using multi-byte character set. +* Names must begin with a letter and may not end with an underscore. +* Only use letters, numbers and underscores in names. +* Avoid the use of multiple consecutive underscores—these can be hard to read. +* Use underscores where you would naturally include a space in the name (first + name becomes `first_name`). +* Avoid abbreviations and if you have to use them make sure they are commonly + understood. + +```sql +SELECT first_name + FROM staff; +``` + +### Tables + +* Use a collective name or, less ideally, a plural form. For example (in order of + preference) `staff` and `employees`. +* Do not prefix with `tbl` or any other such descriptive prefix or Hungarian + notation. +* Never give a table the same name as one of its columns and vice versa. +* Avoid, where possible, concatenating two table names together to create the name + of a relationship table. Rather than `cars_mechanics` prefer `services`. + +### Columns + +* Always use the singular name. +* Where possible avoid simply using `id` as the primary identifier for the table. +* Do not add a column with the same name as its table and vice versa. +* Always use lowercase except where it may make sense not to such as proper nouns. + +### Aliasing or correlations + +* Should relate in some way to the object or expression they are aliasing. +* As a rule of thumb the correlation name should be the first letter of each word + in the object's name. +* If there is already a correlation with the same name then append a number. +* Always include the `AS` keyword—makes it easier to read as it is explicit. +* For computed data (`SUM()` or `AVG()`) use the name you would give it were it + a column defined in the schema. + +```sql +SELECT first_name AS fn + FROM staff AS s1 + JOIN students AS s2 + ON s2.mentor_id = s1.staff_num; +``` +```sql +SELECT SUM(s.monitor_tally) AS monitor_total + FROM staff AS s; +``` + +### Stored procedures + +* The name must contain a verb. +* Do not prefix with `sp_` or any other such descriptive prefix or Hungarian + notation. + +### Uniform suffixes + +The following suffixes have a universal meaning ensuring the columns can be read +and understood easily from SQL code. Use the correct suffix where appropriate. + +* `_id`—a unique identifier such as a column that is a primary key. +* `_status`—flag value or some other status of any type such as + `publication_status`. +* `_total`—the total or sum of a collection of values. +* `_num`—denotes the field contains any kind of number. +* `_name`—signifies a name such as `first_name`. +* `_seq`—contains a contiguous sequence of values. +* `_date`—denotes a column that contains the date of something. +* `_tally`—a count. +* `_size`—the size of something such as a file size or clothing. +* `_addr`—an address for the record could be physical or intangible such as + `ip_addr`. + +## Query syntax + +### Reserved words + +Always use uppercase for the [reserved keywords][reserved-keywords] +like `SELECT` and `WHERE`. + +It is best to avoid the abbreviated keywords and use the full length ones where +available (prefer `ABSOLUTE` to `ABS`). + +Do not use database server specific keywords where an ANSI SQL keyword already +exists performing the same function. This helps to make code more portable. + +```sql +SELECT model_num + FROM phones AS p + WHERE p.release_date > '2014-09-30'; +``` + +### White space + +To make the code easier to read it is important that the correct compliment of +spacing is used. Do not crowd code or remove natural language spaces. + +#### Spaces + +Spaces should be used to line up the code so that the root keywords all end on +the same character boundary. This forms a river down the middle making it easy for +the readers eye to scan over the code and separate the keywords from the +implementation detail. Rivers are [bad in typography][rivers], but helpful here. + +```sql +(SELECT f.species_name, + AVG(f.height) AS average_height, AVG(f.diameter) AS average_diameter + FROM flora AS f + WHERE f.species_name = 'Banksia' + OR f.species_name = 'Sheoak' + OR f.species_name = 'Wattle' + GROUP BY f.species_name, f.observation_date) + + UNION ALL + +(SELECT b.species_name, + AVG(b.height) AS average_height, AVG(b.diameter) AS average_diameter + FROM botanic_garden_flora AS b + WHERE b.species_name = 'Banksia' + OR b.species_name = 'Sheoak' + OR b.species_name = 'Wattle' + GROUP BY b.species_name, b.observation_date) +``` + +Notice that `SELECT`, `FROM`, etc. are all right aligned while the actual column +names and implementation specific details are left aligned. + +Although not exhaustive always include spaces: + +* before and after equals (`=`) +* after commas (`,`) +* surrounding apostrophes (`'`) where not within parentheses or with a trailing + comma or semicolon. + +```sql +SELECT a.title, a.release_date, a.recording_date + FROM albums AS a + WHERE a.title = 'Charcoal Lane' + OR a.title = 'The New Danger'; +``` + +#### Line spacing + +Always include newlines/vertical space: + +* before `AND` or `OR` +* after semicolons to separate queries for easier reading +* after each keyword definition +* after a comma when separating multiple columns into logical groups +* to separate code into related sections, which helps to ease the readability of + large chunks of code. + +Keeping all the keywords aligned to the righthand side and the values left aligned +creates a uniform gap down the middle of query. It makes it much easier to scan +the query definition over quickly too. + +```sql +INSERT INTO albums (title, release_date, recording_date) +VALUES ('Charcoal Lane', '1990-01-01 01:01:01.00000', '1990-01-01 01:01:01.00000'), + ('The New Danger', '2008-01-01 01:01:01.00000', '1990-01-01 01:01:01.00000'); +``` + +```sql +UPDATE albums + SET release_date = '1990-01-01 01:01:01.00000' + WHERE title = 'The New Danger'; +``` + +```sql +SELECT a.title, + a.release_date, a.recording_date, a.production_date -- grouped dates together + FROM albums AS a + WHERE a.title = 'Charcoal Lane' + OR a.title = 'The New Danger'; +``` + +### Indentation + +To ensure that SQL is readable it is important that standards of indentation +are followed. + +#### Joins + +Joins should be indented to the other side of the river and grouped with a new +line where necessary. + +```sql +SELECT r.last_name + FROM riders AS r + INNER JOIN bikes AS b + ON r.bike_vin_num = b.vin_num + AND b.engines > 2 + + INNER JOIN crew AS c + ON r.crew_chief_last_name = c.last_name + AND c.chief = 'Y'; +``` + +#### Subqueries + +Subqueries should also be aligned to the right side of the river and then laid +out using the same style as any other query. Sometimes it will make sense to have +the closing parenthesis on a new line at the same character position as it's +opening partner—this is especially true where you have nested subqueries. + +```sql +SELECT r.last_name, + (SELECT MAX(YEAR(championship_date)) + FROM champions AS c + WHERE c.last_name = r.last_name + AND c.confirmed = 'Y') AS last_championship_year + FROM riders AS r + WHERE r.last_name IN + (SELECT c.last_name + FROM champions AS c + WHERE YEAR(championship_date) > '2008' + AND c.confirmed = 'Y'); +``` + +### Preferred formalisms + +* Make use of `BETWEEN` where possible instead of combining multiple statements + with `AND`. +* Similarly use `IN()` instead of multiple `OR` clauses. +* Where a value needs to be interpreted before leaving the database use the `CASE` + expression. `CASE` statements can be nested to form more complex logical structures. +* Avoid the use of `UNION` clauses and temporary tables where possible. If the + schema can be optimised to remove the reliance on these features then it most + likely should be. + +```sql +SELECT CASE postcode + WHEN 'BN1' THEN 'Brighton' + WHEN 'EH1' THEN 'Edinburgh' + END AS city + FROM office_locations + WHERE country = 'United Kingdom' + AND opening_time BETWEEN 8 AND 9 + AND postcode IN ('EH1', 'BN1', 'NN1', 'KW1') +``` + +## Create syntax + +When declaring schema information it is also important to maintain human +readable code. To facilitate this ensure the column definitions are ordered and +grouped where it makes sense to do so. + +Indent column definitions by four (4) spaces within the `CREATE` definition. + +### Choosing data types + +* Where possible do not use vendor specific data types—these are not portable and + may not be available in older versions of the same vendor's software. +* Only use `REAL` or `FLOAT` types where it is strictly necessary for floating + point mathematics otherwise prefer `NUMERIC` and `DECIMAL` at all times. Floating + point rounding errors are a nuisance! + +### Specifying default values + +* The default value must be the same type as the column—if a column is declared + a `DECIMAL` do not provide an `INTEGER` default value. +* Default values must follow the data type declaration and come before any + `NOT NULL` statement. + +### Constraints and keys + +Constraints and their subset, keys, are a very important component of any +database definition. They can quickly become very difficult to read and reason +about though so it is important that a standard set of guidelines are followed. + +#### Choosing keys + +Deciding the column(s) that will form the keys in the definition should be a +carefully considered activity as it will effect performance and data integrity. + +1. The key should be unique to some degree. +2. Consistency in terms of data type for the value across the schema and a lower + likelihood of this changing in the future. +3. Can the value be validated against a standard format (such as one published by + ISO)? Encouraging conformity to point 2. +4. Keeping the key as simple as possible whilst not being scared to use compound + keys where necessary. + +It is a reasoned and considered balancing act to be performed at the definition +of a database. Should requirements evolve in the future it is possible to make +changes to the definitions to keep them up to date. + +#### Defining constraints + +Once the keys are decided it is possible to define them in the system using +constraints along with field value validation. + +##### General + +* Tables must have at least one key to be complete and useful. +* Constraints should be given a custom name excepting `UNIQUE`, `PRIMARY KEY` + and `FOREIGN KEY` where the database vendor will generally supply sufficiently + intelligible names automatically. + +##### Layout and order + +* Specify the primary key first right after the `CREATE TABLE` statement. +* Constraints should be defined directly beneath the column they correspond to. + Indent the constraint so that it aligns to the right of the column name. +* If it is a multi-column constraint then consider putting it as close to both + column definitions as possible and where this is difficult as a last resort + include them at the end of the `CREATE TABLE` definition. +* If it is a table level constraint that applies to the entire table then it + should also appear at the end. +* Use alphabetical order where `ON DELETE` comes before `ON UPDATE`. +* If it make senses to do so align each aspect of the query on the same character + position. For example all `NOT NULL` definitions could start at the same + character position. This is not hard and fast, but it certainly makes the code + much easier to scan and read. + +##### Validation + +* Use `LIKE` and `SIMILAR TO` constraints to ensure the integrity of strings + where the format is known. +* Where the ultimate range of a numerical value is known it must be written as a + range `CHECK()` to prevent incorrect values entering the database or the silent + truncation of data too large to fit the column definition. In the least it + should check that the value is greater than zero in most cases. +* `CHECK()` constraints should be kept in separate clauses to ease debugging. + +##### Example + +```sql +CREATE TABLE staff ( + PRIMARY KEY (staff_num), + staff_num INT(5) NOT NULL, + first_name VARCHAR(100) NOT NULL, + pens_in_drawer INT(2) NOT NULL, + CONSTRAINT pens_in_drawer_range + CHECK(pens_in_drawer >= 1 AND pens_in_drawer < 100) +); +``` + +### Designs to avoid + +* Object oriented design principles do not effectively translate to relational + database designs—avoid this pitfall. +* Placing the value in one column and the units in another column. The column + should make the units self evident to prevent the requirement to combine + columns again later in the application. Use `CHECK()` to ensure valid data is + inserted into the column. +* [EAV (Entity Attribute Value)][eav] tables—use a specialist product intended for + handling such schema-less data instead. +* Splitting up data that should be in one table across many because of arbitrary + concerns such as time-based archiving or location in a multi-national + organisation. Later queries must then work across multiple tables with `UNION` + rather than just simply querying one table. + + +## Appendix + +### Reserved keyword reference + +A list of ANSI SQL (92, 99 and 2003), MySQL 3 to 5.x, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC and Oracle 10.2 reserved keywords. + +```sql +A +ABORT +ABS +ABSOLUTE +ACCESS +ACTION +ADA +ADD +ADMIN +AFTER +AGGREGATE +ALIAS +ALL +ALLOCATE +ALSO +ALTER +ALWAYS +ANALYSE +ANALYZE +AND +ANY +ARE +ARRAY +AS +ASC +ASENSITIVE +ASSERTION +ASSIGNMENT +ASYMMETRIC +AT +ATOMIC +ATTRIBUTE +ATTRIBUTES +AUDIT +AUTHORIZATION +AUTO_INCREMENT +AVG +AVG_ROW_LENGTH +BACKUP +BACKWARD +BEFORE +BEGIN +BERNOULLI +BETWEEN +BIGINT +BINARY +BIT +BIT_LENGTH +BITVAR +BLOB +BOOL +BOOLEAN +BOTH +BREADTH +BREAK +BROWSE +BULK +BY +C +CACHE +CALL +CALLED +CARDINALITY +CASCADE +CASCADED +CASE +CAST +CATALOG +CATALOG_NAME +CEIL +CEILING +CHAIN +CHANGE +CHAR +CHAR_LENGTH +CHARACTER +CHARACTER_LENGTH +CHARACTER_SET_CATALOG +CHARACTER_SET_NAME +CHARACTER_SET_SCHEMA +CHARACTERISTICS +CHARACTERS +CHECK +CHECKED +CHECKPOINT +CHECKSUM +CLASS +CLASS_ORIGIN +CLOB +CLOSE +CLUSTER +CLUSTERED +COALESCE +COBOL +COLLATE +COLLATION +COLLATION_CATALOG +COLLATION_NAME +COLLATION_SCHEMA +COLLECT +COLUMN +COLUMN_NAME +COLUMNS +COMMAND_FUNCTION +COMMAND_FUNCTION_CODE +COMMENT +COMMIT +COMMITTED +COMPLETION +COMPRESS +COMPUTE +CONDITION +CONDITION_NUMBER +CONNECT +CONNECTION +CONNECTION_NAME +CONSTRAINT +CONSTRAINT_CATALOG +CONSTRAINT_NAME +CONSTRAINT_SCHEMA +CONSTRAINTS +CONSTRUCTOR +CONTAINS +CONTAINSTABLE +CONTINUE +CONVERSION +CONVERT +COPY +CORR +CORRESPONDING +COUNT +COVAR_POP +COVAR_SAMP +CREATE +CREATEDB +CREATEROLE +CREATEUSER +CROSS +CSV +CUBE +CUME_DIST +CURRENT +CURRENT_DATE +CURRENT_DEFAULT_TRANSFORM_GROUP +CURRENT_PATH +CURRENT_ROLE +CURRENT_TIME +CURRENT_TIMESTAMP +CURRENT_TRANSFORM_GROUP_FOR_TYPE +CURRENT_USER +CURSOR +CURSOR_NAME +CYCLE +DATA +DATABASE +DATABASES +DATE +DATETIME +DATETIME_INTERVAL_CODE +DATETIME_INTERVAL_PRECISION +DAY +DAY_HOUR +DAY_MICROSECOND +DAY_MINUTE +DAY_SECOND +DAYOFMONTH +DAYOFWEEK +DAYOFYEAR +DBCC +DEALLOCATE +DEC +DECIMAL +DECLARE +DEFAULT +DEFAULTS +DEFERRABLE +DEFERRED +DEFINED +DEFINER +DEGREE +DELAY_KEY_WRITE +DELAYED +DELETE +DELIMITER +DELIMITERS +DENSE_RANK +DENY +DEPTH +DEREF +DERIVED +DESC +DESCRIBE +DESCRIPTOR +DESTROY +DESTRUCTOR +DETERMINISTIC +DIAGNOSTICS +DICTIONARY +DISABLE +DISCONNECT +DISK +DISPATCH +DISTINCT +DISTINCTROW +DISTRIBUTED +DIV +DO +DOMAIN +DOUBLE +DROP +DUAL +DUMMY +DUMP +DYNAMIC +DYNAMIC_FUNCTION +DYNAMIC_FUNCTION_CODE +EACH +ELEMENT +ELSE +ELSEIF +ENABLE +ENCLOSED +ENCODING +ENCRYPTED +END +END-EXEC +ENUM +EQUALS +ERRLVL +ESCAPE +ESCAPED +EVERY +EXCEPT +EXCEPTION +EXCLUDE +EXCLUDING +EXCLUSIVE +EXEC +EXECUTE +EXISTING +EXISTS +EXIT +EXP +EXPLAIN +EXTERNAL +EXTRACT +FALSE +FETCH +FIELDS +FILE +FILLFACTOR +FILTER +FINAL +FIRST +FLOAT +FLOAT4 +FLOAT8 +FLOOR +FLUSH +FOLLOWING +FOR +FORCE +FOREIGN +FORTRAN +FORWARD +FOUND +FREE +FREETEXT +FREETEXTTABLE +FREEZE +FROM +FULL +FULLTEXT +FUNCTION +FUSION +G +GENERAL +GENERATED +GET +GLOBAL +GO +GOTO +GRANT +GRANTED +GRANTS +GREATEST +GROUP +GROUPING +HANDLER +HAVING +HEADER +HEAP +HIERARCHY +HIGH_PRIORITY +HOLD +HOLDLOCK +HOST +HOSTS +HOUR +HOUR_MICROSECOND +HOUR_MINUTE +HOUR_SECOND +IDENTIFIED +IDENTITY +IDENTITY_INSERT +IDENTITYCOL +IF +IGNORE +ILIKE +IMMEDIATE +IMMUTABLE +IMPLEMENTATION +IMPLICIT +IN +INCLUDE +INCLUDING +INCREMENT +INDEX +INDICATOR +INFILE +INFIX +INHERIT +INHERITS +INITIAL +INITIALIZE +INITIALLY +INNER +INOUT +INPUT +INSENSITIVE +INSERT +INSERT_ID +INSTANCE +INSTANTIABLE +INSTEAD +INT +INT1 +INT2 +INT3 +INT4 +INT8 +INTEGER +INTERSECT +INTERSECTION +INTERVAL +INTO +INVOKER +IS +ISAM +ISNULL +ISOLATION +ITERATE +JOIN +K +KEY +KEY_MEMBER +KEY_TYPE +KEYS +KILL +LANCOMPILER +LANGUAGE +LARGE +LAST +LAST_INSERT_ID +LATERAL +LEADING +LEAST +LEAVE +LEFT +LENGTH +LESS +LEVEL +LIKE +LIMIT +LINENO +LINES +LISTEN +LN +LOAD +LOCAL +LOCALTIME +LOCALTIMESTAMP +LOCATION +LOCATOR +LOCK +LOGIN +LOGS +LONG +LONGBLOB +LONGTEXT +LOOP +LOW_PRIORITY +LOWER +M +MAP +MATCH +MATCHED +MAX +MAX_ROWS +MAXEXTENTS +MAXVALUE +MEDIUMBLOB +MEDIUMINT +MEDIUMTEXT +MEMBER +MERGE +MESSAGE_LENGTH +MESSAGE_OCTET_LENGTH +MESSAGE_TEXT +METHOD +MIDDLEINT +MIN +MIN_ROWS +MINUS +MINUTE +MINUTE_MICROSECOND +MINUTE_SECOND +MINVALUE +MLSLABEL +MOD +MODE +MODIFIES +MODIFY +MODULE +MONTH +MONTHNAME +MORE +MOVE +MULTISET +MUMPS +MYISAM +NAME +NAMES +NATIONAL +NATURAL +NCHAR +NCLOB +NESTING +NEW +NEXT +NO +NO_WRITE_TO_BINLOG +NOAUDIT +NOCHECK +NOCOMPRESS +NOCREATEDB +NOCREATEROLE +NOCREATEUSER +NOINHERIT +NOLOGIN +NONCLUSTERED +NONE +NORMALIZE +NORMALIZED +NOSUPERUSER +NOT +NOTHING +NOTIFY +NOTNULL +NOWAIT +NULL +NULLABLE +NULLIF +NULLS +NUMBER +NUMERIC +OBJECT +OCTET_LENGTH +OCTETS +OF +OFF +OFFLINE +OFFSET +OFFSETS +OIDS +OLD +ON +ONLINE +ONLY +OPEN +OPENDATASOURCE +OPENQUERY +OPENROWSET +OPENXML +OPERATION +OPERATOR +OPTIMIZE +OPTION +OPTIONALLY +OPTIONS +OR +ORDER +ORDERING +ORDINALITY +OTHERS +OUT +OUTER +OUTFILE +OUTPUT +OVER +OVERLAPS +OVERLAY +OVERRIDING +OWNER +PACK_KEYS +PAD +PARAMETER +PARAMETER_MODE +PARAMETER_NAME +PARAMETER_ORDINAL_POSITION +PARAMETER_SPECIFIC_CATALOG +PARAMETER_SPECIFIC_NAME +PARAMETER_SPECIFIC_SCHEMA +PARAMETERS +PARTIAL +PARTITION +PASCAL +PASSWORD +PATH +PCTFREE +PERCENT +PERCENT_RANK +PERCENTILE_CONT +PERCENTILE_DISC +PLACING +PLAN +PLI +POSITION +POSTFIX +POWER +PRECEDING +PRECISION +PREFIX +PREORDER +PREPARE +PREPARED +PRESERVE +PRIMARY +PRINT +PRIOR +PRIVILEGES +PROC +PROCEDURAL +PROCEDURE +PROCESS +PROCESSLIST +PUBLIC +PURGE +QUOTE +RAID0 +RAISERROR +RANGE +RANK +RAW +READ +READS +READTEXT +REAL +RECHECK +RECONFIGURE +RECURSIVE +REF +REFERENCES +REFERENCING +REGEXP +REGR_AVGX +REGR_AVGY +REGR_COUNT +REGR_INTERCEPT +REGR_R2 +REGR_SLOPE +REGR_SXX +REGR_SXY +REGR_SYY +REINDEX +RELATIVE +RELEASE +RELOAD +RENAME +REPEAT +REPEATABLE +REPLACE +REPLICATION +REQUIRE +RESET +RESIGNAL +RESOURCE +RESTART +RESTORE +RESTRICT +RESULT +RETURN +RETURNED_CARDINALITY +RETURNED_LENGTH +RETURNED_OCTET_LENGTH +RETURNED_SQLSTATE +RETURNS +REVOKE +RIGHT +RLIKE +ROLE +ROLLBACK +ROLLUP +ROUTINE +ROUTINE_CATALOG +ROUTINE_NAME +ROUTINE_SCHEMA +ROW +ROW_COUNT +ROW_NUMBER +ROWCOUNT +ROWGUIDCOL +ROWID +ROWNUM +ROWS +RULE +SAVE +SAVEPOINT +SCALE +SCHEMA +SCHEMA_NAME +SCHEMAS +SCOPE +SCOPE_CATALOG +SCOPE_NAME +SCOPE_SCHEMA +SCROLL +SEARCH +SECOND +SECOND_MICROSECOND +SECTION +SECURITY +SELECT +SELF +SENSITIVE +SEPARATOR +SEQUENCE +SERIALIZABLE +SERVER_NAME +SESSION +SESSION_USER +SET +SETOF +SETS +SETUSER +SHARE +SHOW +SHUTDOWN +SIGNAL +SIMILAR +SIMPLE +SIZE +SMALLINT +SOME +SONAME +SOURCE +SPACE +SPATIAL +SPECIFIC +SPECIFIC_NAME +SPECIFICTYPE +SQL +SQL_BIG_RESULT +SQL_BIG_SELECTS +SQL_BIG_TABLES +SQL_CALC_FOUND_ROWS +SQL_LOG_OFF +SQL_LOG_UPDATE +SQL_LOW_PRIORITY_UPDATES +SQL_SELECT_LIMIT +SQL_SMALL_RESULT +SQL_WARNINGS +SQLCA +SQLCODE +SQLERROR +SQLEXCEPTION +SQLSTATE +SQLWARNING +SQRT +SSL +STABLE +START +STARTING +STATE +STATEMENT +STATIC +STATISTICS +STATUS +STDDEV_POP +STDDEV_SAMP +STDIN +STDOUT +STORAGE +STRAIGHT_JOIN +STRICT +STRING +STRUCTURE +STYLE +SUBCLASS_ORIGIN +SUBLIST +SUBMULTISET +SUBSTRING +SUCCESSFUL +SUM +SUPERUSER +SYMMETRIC +SYNONYM +SYSDATE +SYSID +SYSTEM +SYSTEM_USER +TABLE +TABLE_NAME +TABLES +TABLESAMPLE +TABLESPACE +TEMP +TEMPLATE +TEMPORARY +TERMINATE +TERMINATED +TEXT +TEXTSIZE +THAN +THEN +TIES +TIME +TIMESTAMP +TIMEZONE_HOUR +TIMEZONE_MINUTE +TINYBLOB +TINYINT +TINYTEXT +TO +TOAST +TOP +TOP_LEVEL_COUNT +TRAILING +TRAN +TRANSACTION +TRANSACTION_ACTIVE +TRANSACTIONS_COMMITTED +TRANSACTIONS_ROLLED_BACK +TRANSFORM +TRANSFORMS +TRANSLATE +TRANSLATION +TREAT +TRIGGER +TRIGGER_CATALOG +TRIGGER_NAME +TRIGGER_SCHEMA +TRIM +TRUE +TRUNCATE +TRUSTED +TSEQUAL +TYPE +UESCAPE +UID +UNBOUNDED +UNCOMMITTED +UNDER +UNDO +UNENCRYPTED +UNION +UNIQUE +UNKNOWN +UNLISTEN +UNLOCK +UNNAMED +UNNEST +UNSIGNED +UNTIL +UPDATE +UPDATETEXT +UPPER +USAGE +USE +USER +USER_DEFINED_TYPE_CATALOG +USER_DEFINED_TYPE_CODE +USER_DEFINED_TYPE_NAME +USER_DEFINED_TYPE_SCHEMA +USING +UTC_DATE +UTC_TIME +UTC_TIMESTAMP +VACUUM +VALID +VALIDATE +VALIDATOR +VALUE +VALUES +VAR_POP +VAR_SAMP +VARBINARY +VARCHAR +VARCHAR2 +VARCHARACTER +VARIABLE +VARIABLES +VARYING +VERBOSE +VIEW +VOLATILE +WAITFOR +WHEN +WHENEVER +WHERE +WHILE +WIDTH_BUCKET +WINDOW +WITH +WITHIN +WITHOUT +WORK +WRITE +WRITETEXT +X509 +XOR +YEAR +YEAR_MONTH +ZEROFILL +ZONE +``` + +[simon]: https://www.simonholywell.com/?utm_source=sqlstyle.guide&utm_medium=link&utm_campaign=md-document + "SimonHolywell.com" +[issue]: https://github.com/treffynnon/sqlstyle.guide/issues + "SQL style guide issues on GitHub" +[fork]: https://github.com/treffynnon/sqlstyle.guide/fork + "Fork SQL style guide on GitHub" +[pull]: https://github.com/treffynnon/sqlstyle.guide/pulls/ + "SQL style guide pull requests on GitHub" +[celko]: https://www.amazon.com/gp/product/0120887975/ref=as_li_ss_tl?ie=UTF8&linkCode=ll1&tag=treffynnon-20&linkId=9c88eac8cd420e979675c815771313d5 + "Joe Celko's SQL Programming Style (The Morgan Kaufmann Series in Data Management Systems)" +[dl-md]: https://raw.githubusercontent.com/treffynnon/sqlstyle.guide/gh-pages/_includes/sqlstyle.guide.md + "Download the guide in Markdown format" +[iso-8601]: https://en.wikipedia.org/wiki/ISO_8601 + "Wikipedia: ISO 8601" +[rivers]: http://practicaltypography.com/one-space-between-sentences.html + "Practical Typography: one space between sentences" +[reserved-keywords]: #reserved-keyword-reference + "Reserved keyword reference" +[eav]: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model + "Wikipedia: Entity–attribute–value model" +[sqlstyleguide]: http://www.sqlstyle.guide + "SQL style guide by Simon Holywell" +[licence]: http://creativecommons.org/licenses/by-sa/4.0/ + "Creative Commons Attribution-ShareAlike 4.0 International License" From 741138e09c973589cef798340544b28a4783af7f Mon Sep 17 00:00:00 2001 From: Unknown Date: Sun, 16 Apr 2017 20:51:20 -0300 Subject: [PATCH 02/29] Translated General: Do / Aviod --- _includes/sqlstyle.guide.pt-br.md | 47 ++++++++++++++++--------------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 3540c92..dc02b37 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -22,21 +22,22 @@ O Guia De Estilo SQL por [Simon Holywell][simon] é licenciaso sob a [Creative Commons Attribution-ShareAlike 4.0 International License][licence]. Baseado no trabalho em [http://www.sqlstyle.guide][sqlstyleguide]. -## General +## Geral -### Do +### Faça -* Use consistent and descriptive identifiers and names. -* Make judicious use of white space and indentation to make code easier to read. -* Store [ISO-8601][iso-8601] compliant time and date information - (`YYYY-MM-DD HH:MM:SS.SSSSS`). -* Try to use only standard SQL functions instead of vendor specific functions for - reasons of portability. -* Keep code succinct and devoid of redundant SQL—such as unnecessary quoting or - parentheses or `WHERE` clauses that can otherwise be derived. -* Include comments in SQL code where necessary. Use the C style opening `/*` and - closing `*/` where possible otherwise precede comments with `--` and finish - them with a new line. +* Utilize identificadores e nomes consistentes e descritivos. +* Faça uso criterioso de espaços em branco e indentação para tornar o código +mais fácil de ler. +* Armazene informações de data e hora compatíveis com [ISO-8601][iso-8601] +(`YYYY-MM-DD HH:MM:SS.SSSSS`). +* Por questões de portabilidade, tente utilizar apenas funções SQL padrão ao +invés de funções específicas de servidores SQL de empresas. +* Mantenha o código sucinto e desprovido de SQL redundante - como adição de +aspas e parênteses desencessários, ou cláusulas WHERE que podem ser derivadas. +* Inclua comentários no código SQL quando necessário. Utilize o estilo C abrindo +com `/*` e fechando com `*/` onde possível. Onde não for possível, preceda os +comentários com `--` e termine com uma nova linha. ```sql SELECT file_hash -- stored ssdeep hash @@ -51,17 +52,17 @@ UPDATE file_system WHERE file_name = '.vimrc'; ``` -### Avoid +### Evite -* CamelCase—it is difficult to scan quickly. -* Descriptive prefixes or Hungarian notation such as `sp_` or `tbl`. -* Plurals—use the more natural collective term where possible instead. For example - `staff` instead of `employees` or `people` instead of `individuals`. -* Quoted identifiers—if you must use them then stick to SQL92 double quotes for - portability (you may need to configure your SQL server to support this depending - on vendor). -* Object oriented design principles should not be applied to SQL or database - structures. +* CamelCase—é dificil para efetuar buscas rapidamente. +* Prefixos descritivos ou notação Húngara como `sp_` ou `tbl`. +* Plurais—utilize um termo coletivo onde possível. Por exemplo, + `pessoal` ao invés de `funcionários` ou `pessoa` no lugar de `indivíduos`. +* Identificadores entre aspas-se você precisar utilizá-los, então utilize a as + aspas duplas SQL92 por questões de portabilidade (dependendo da desenvolvedora, + pode ser necessário configurar seu servidor SQL para suportar isso). +* Princípios de design orientado a objetos não devem ser aplicados ao SQL ou + a estrutura de bancos de dados. ## Naming conventions From 4525dab5b0a3d2c8252c364f53a41c06241522f9 Mon Sep 17 00:00:00 2001 From: Unknown Date: Sun, 16 Apr 2017 21:02:19 -0300 Subject: [PATCH 03/29] Translating Naming Conventions: General / Tables --- _includes/sqlstyle.guide.pt-br.md | 45 ++++++++++++++++--------------- 1 file changed, 24 insertions(+), 21 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index dc02b37..3aef15a 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -64,36 +64,39 @@ UPDATE file_system * Princípios de design orientado a objetos não devem ser aplicados ao SQL ou a estrutura de bancos de dados. -## Naming conventions +## Convenções de nomenclatura -### General +### Geral -* Ensure the name is unique and does not exist as a - [reserved keyword][reserved-keywords]. -* Keep the length to a maximum of 30 bytes—in practice this is 30 characters - unless you are using multi-byte character set. -* Names must begin with a letter and may not end with an underscore. -* Only use letters, numbers and underscores in names. -* Avoid the use of multiple consecutive underscores—these can be hard to read. -* Use underscores where you would naturally include a space in the name (first - name becomes `first_name`). -* Avoid abbreviations and if you have to use them make sure they are commonly - understood. +* Tenha certeza que o nome é único e não existe como uma + [palavra reservada][reserved-keywords]. +* Mantenha o comprimento até um tamanho máximo de 30 bytes-na prática isso são + 30 caracateres, a não ser que você esteja utilizando um conjunto de + caracateres multi-byte. +* Nomes devem começar com uma letra e não devem terminar com underscore. +* Utilize apenas letras, números e underscores em nomes. +* Evite o uso de multiplos underscores consecutivos-eles podem ser dificeis de +se ler. +* Utilize underscores onde você normalemnte incluiria um espaço no nome + (primeiro nome se torna `primeiro_nome`). +* Evite abreviações. Se você precisar utilizá-las, tenha certeza de que elas + serão amplamente compreendidas. ```sql SELECT first_name FROM staff; ``` -### Tables +### Tabelas -* Use a collective name or, less ideally, a plural form. For example (in order of - preference) `staff` and `employees`. -* Do not prefix with `tbl` or any other such descriptive prefix or Hungarian - notation. -* Never give a table the same name as one of its columns and vice versa. -* Avoid, where possible, concatenating two table names together to create the name - of a relationship table. Rather than `cars_mechanics` prefer `services`. +* Utilize um nome coletivo ou de forma menos ideal, uma forma plural. Por exemplo, + (em ordem de preferência) `pessoal` e `empregados`. +* Não utilize prefixos com `tbl` ou qualquer outro prefixo descritivo ou notação + Húngara. +* Nunca dê a uma tabela o mesmo nome de uma das suas colunas e vice versa. +* Evite, quando possível, concatenar dois nomes de tabelas para criar o nome de + uma tabela de relacionamento. Ao invés de utilizar `mecanicos_de_carro`, + prefira `serviços`. ### Columns From 393c4cbec6dfc30f271952a2aa21b12ccaabbf09 Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 00:07:39 -0300 Subject: [PATCH 04/29] Translating lots of sections Columns / Aliasing and Correlations / Stored Procedures / Uniform Sufifxes --- _includes/sqlstyle.guide.pt-br.md | 66 ++++++++++++++++--------------- 1 file changed, 35 insertions(+), 31 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 3aef15a..a03944f 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -96,24 +96,28 @@ SELECT first_name * Nunca dê a uma tabela o mesmo nome de uma das suas colunas e vice versa. * Evite, quando possível, concatenar dois nomes de tabelas para criar o nome de uma tabela de relacionamento. Ao invés de utilizar `mecanicos_de_carro`, - prefira `serviços`. + prefira `servicos`. -### Columns +### Colunas -* Always use the singular name. -* Where possible avoid simply using `id` as the primary identifier for the table. -* Do not add a column with the same name as its table and vice versa. -* Always use lowercase except where it may make sense not to such as proper nouns. -### Aliasing or correlations +* Sempre utilize nomes no singular. +* Quando possível, evite simplesmente usar `id` como o identificador primário + da tabela. +* Não adicione uma coluna com o mesmo nome da tabela e vice versa. +* Sempre utilize caixa baixa, exceto onde fizer sentido a sua utilização. + Como em nomes próprios. -* Should relate in some way to the object or expression they are aliasing. -* As a rule of thumb the correlation name should be the first letter of each word - in the object's name. -* If there is already a correlation with the same name then append a number. -* Always include the `AS` keyword—makes it easier to read as it is explicit. -* For computed data (`SUM()` or `AVG()`) use the name you would give it were it - a column defined in the schema. +### Aliasing ou correlações + +* Deve se relacionar de alguma forma com o objeto ou expressão em que o aliasing + está sendo aplicado. +* Como regra geral, o nome da correlação deve ser a primeira letra de cada palavra + do nome do objeto. +* Se já existe uma correlação com o mesmo nome, acrescente um número. +* Sempre inclua a palavra-chave `AS`-torna mais fácil de ler, pois é explícito. +* Para dados computados (`SUM()` ou `AVG()`), utilize o nome que você daria se + fosse uma coluna definida no schema. ```sql SELECT first_name AS fn @@ -128,27 +132,27 @@ SELECT SUM(s.monitor_tally) AS monitor_total ### Stored procedures -* The name must contain a verb. -* Do not prefix with `sp_` or any other such descriptive prefix or Hungarian - notation. +* O nome deve conter um verbo. +* Não adicione `sp_` ou qualquer outro prefixo descritivo ou + notação Húngara. -### Uniform suffixes +### Sufixos uniformes -The following suffixes have a universal meaning ensuring the columns can be read -and understood easily from SQL code. Use the correct suffix where appropriate. +Os sufixos seguintes tem sentido universal, garantindo que as colunas possam ser +lidas e compreendedidas facilmente no código SQL. Utilize os sufixos corretos +onde for apropriado. -* `_id`—a unique identifier such as a column that is a primary key. -* `_status`—flag value or some other status of any type such as - `publication_status`. -* `_total`—the total or sum of a collection of values. -* `_num`—denotes the field contains any kind of number. -* `_name`—signifies a name such as `first_name`. +* `_id`—um identificador único, como uma coluna que é a chave primária. +* `_status`—flag value ou outro status de qualquer tipo, como `publication_status`. +* `_total`—o total ou a soma de uma coleção de valores. +* `_num`—indica que o campo contém qualquer tipo de número. +* `_name`—significa um nome, como `first_name`. +* `_seq`—contém uma sequência contígua de valores. * `_seq`—contains a contiguous sequence of values. -* `_date`—denotes a column that contains the date of something. -* `_tally`—a count. -* `_size`—the size of something such as a file size or clothing. -* `_addr`—an address for the record could be physical or intangible such as - `ip_addr`. +* `_date`—indica uma coluna que contém a data de alguma coisa. +* `_tally`—uma contagem. +* `_size`—o tamanho de algo, como o tamanho de um arquivo ou de uma roupa. +* `_addr`—um endereço. Pode ser físico ou intangível, como por exemplo `ip_addr`. ## Query syntax From 29151390fa4b8470e5137f1afd9368bdc6cfcd3a Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 01:15:03 -0300 Subject: [PATCH 05/29] Translating Reserved Words / White space --- _includes/sqlstyle.guide.pt-br.md | 41 +++++++++++++++++-------------- 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index a03944f..7ad5ae0 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -154,18 +154,19 @@ onde for apropriado. * `_size`—o tamanho de algo, como o tamanho de um arquivo ou de uma roupa. * `_addr`—um endereço. Pode ser físico ou intangível, como por exemplo `ip_addr`. -## Query syntax +## Sintaxe de Queries -### Reserved words +### Palavras reservadas -Always use uppercase for the [reserved keywords][reserved-keywords] -like `SELECT` and `WHERE`. +Sempre utilize caixa alta para as [palavras-chave reservadas][reserved-keywords] +como `SELECT` e `WHERE` -It is best to avoid the abbreviated keywords and use the full length ones where -available (prefer `ABSOLUTE` to `ABS`). +É melhor evitar palaras reservadas abreviadas e utilizar as que tem o nome +completo (prefira `ABSOLUTE` ao invés de `ABS`). -Do not use database server specific keywords where an ANSI SQL keyword already -exists performing the same function. This helps to make code more portable. +Não utilize palavras-chave específicas do servidor de banco de dados onde uma +palavra-chave ANSI SQL já existe performando a mesma função. Isso ajuda a manter +o código mais portátil. ```sql SELECT model_num @@ -173,17 +174,20 @@ SELECT model_num WHERE p.release_date > '2014-09-30'; ``` -### White space +### Espaços em branco -To make the code easier to read it is important that the correct compliment of -spacing is used. Do not crowd code or remove natural language spaces. +Para tornar o código mais fácil de ler, é importante que o cumprimento correto +de espaçamento esteja sendo utilizado. Não coloque código ou remova espaços +naturais da linguagem. -#### Spaces +#### Espaços + +Espaços devem ser utilizados para alinhar o código, de forma que as palavras-chaves +raíz terminem sempre no mesmo limite de caracteres. Isso forma um rio no meio, +tornando fácil para os leitores baterem o olho, visualizar o código e separar as +palavras-chave dos detalhes de implementação. Rios são [ruins na tipografia][rivers], +mas úteis aqui. -Spaces should be used to line up the code so that the root keywords all end on -the same character boundary. This forms a river down the middle making it easy for -the readers eye to scan over the code and separate the keywords from the -implementation detail. Rivers are [bad in typography][rivers], but helpful here. ```sql (SELECT f.species_name, @@ -205,8 +209,9 @@ implementation detail. Rivers are [bad in typography][rivers], but helpful here. GROUP BY b.species_name, b.observation_date) ``` -Notice that `SELECT`, `FROM`, etc. are all right aligned while the actual column -names and implementation specific details are left aligned. +Notuqe que o `SELECT`, `FROM`, etc. estão todos a direita, alinhados, enquanto +os nomes das colunas em si e os detalhes específicos de implementação estão +alinhados à esquerda. Although not exhaustive always include spaces: From 366ac735505c2c14482bd0c757180920cbb21bfb Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 10:45:29 -0300 Subject: [PATCH 06/29] Minor Fixes --- _includes/sqlstyle.guide.pt-br.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 7ad5ae0..06b5cc0 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -58,7 +58,7 @@ UPDATE file_system * Prefixos descritivos ou notação Húngara como `sp_` ou `tbl`. * Plurais—utilize um termo coletivo onde possível. Por exemplo, `pessoal` ao invés de `funcionários` ou `pessoa` no lugar de `indivíduos`. -* Identificadores entre aspas-se você precisar utilizá-los, então utilize a as +* Identificadores entre aspas—se você precisar utilizá-los, então utilize a as aspas duplas SQL92 por questões de portabilidade (dependendo da desenvolvedora, pode ser necessário configurar seu servidor SQL para suportar isso). * Princípios de design orientado a objetos não devem ser aplicados ao SQL ou @@ -161,12 +161,12 @@ onde for apropriado. Sempre utilize caixa alta para as [palavras-chave reservadas][reserved-keywords] como `SELECT` e `WHERE` -É melhor evitar palaras reservadas abreviadas e utilizar as que tem o nome -completo (prefira `ABSOLUTE` ao invés de `ABS`). +É melhor evitar palavras-chave reservadas abreviadas; utilize suas variações com +nome completo (use `ABSOLUTE` ao invés de `ABS`). -Não utilize palavras-chave específicas do servidor de banco de dados onde uma -palavra-chave ANSI SQL já existe performando a mesma função. Isso ajuda a manter -o código mais portátil. +Não utilize palavras-chave de servidor de banco de dados específico onde é possível +utilizar palavras-chave ANSI SQL já existentes e que tenham a mesma função. +Isso ajuda na portabilidade do código. ```sql SELECT model_num From d67bbf968bf1d98ff306d8cb49b5a51155fe0c5b Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 11:18:32 -0300 Subject: [PATCH 07/29] Translating Spaces Translated: - Line spacing - Indentation - Preferred formalisms --- _includes/sqlstyle.guide.pt-br.md | 80 +++++++++++++++---------------- 1 file changed, 39 insertions(+), 41 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 06b5cc0..beb357b 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -182,12 +182,10 @@ naturais da linguagem. #### Espaços -Espaços devem ser utilizados para alinhar o código, de forma que as palavras-chaves -raíz terminem sempre no mesmo limite de caracteres. Isso forma um rio no meio, -tornando fácil para os leitores baterem o olho, visualizar o código e separar as -palavras-chave dos detalhes de implementação. Rios são [ruins na tipografia][rivers], -mas úteis aqui. - +Espaços devem ser utilizados para alinhar o código, de forma que as palavras-chave +terminem sempre no mesmo limite de caracteres. Isso forma um rio tipográfico, +tornando fácil bater olho, visualizar o código e separar as palavras-chave dos +detalhes de implementação. Rios são [ruins na tipografia][rivers], mas úteis aqui. ```sql (SELECT f.species_name, @@ -209,16 +207,16 @@ mas úteis aqui. GROUP BY b.species_name, b.observation_date) ``` -Notuqe que o `SELECT`, `FROM`, etc. estão todos a direita, alinhados, enquanto +Note que o `SELECT`, `FROM`, etc. estão todos a direita, alinhados, enquanto os nomes das colunas em si e os detalhes específicos de implementação estão alinhados à esquerda. -Although not exhaustive always include spaces: +Sempre inclua espaços: -* before and after equals (`=`) -* after commas (`,`) -* surrounding apostrophes (`'`) where not within parentheses or with a trailing - comma or semicolon. +* antes de depois do símbolo igual (`=`) +* depois de vírgulas (`,`) +* ao redor de apóstrofes (`'`) caso não estejam entre parênteses, com uma vírgula + ou ponto e vírgula. ```sql SELECT a.title, a.release_date, a.recording_date @@ -227,20 +225,20 @@ SELECT a.title, a.release_date, a.recording_date OR a.title = 'The New Danger'; ``` -#### Line spacing +#### Espaçamento de linhas -Always include newlines/vertical space: +Sempre inclua novas linhas/espaço vertical: -* before `AND` or `OR` -* after semicolons to separate queries for easier reading -* after each keyword definition -* after a comma when separating multiple columns into logical groups -* to separate code into related sections, which helps to ease the readability of - large chunks of code. +* antes de `AND` ou `OR` +* depois de vírgulas, separando as queries para uma leitura mais fácil +* depois de cada definição de palavras-chave +* depois de um ponto, quando seperando múltiplas colunas em grupos lógicos +* para separar código em seções relacionadas, o que ajuda na legibilidade de + grandes pedaços de código. -Keeping all the keywords aligned to the righthand side and the values left aligned -creates a uniform gap down the middle of query. It makes it much easier to scan -the query definition over quickly too. +Manter todas as palavras-chave alinhadas ao lado direito e os valores alinhados +ao lado esquerdo, cria uma lacuna no meio da query. Isso torna muito mais fácil +e rápido a análise da definição da query. ```sql INSERT INTO albums (title, release_date, recording_date) @@ -262,15 +260,15 @@ SELECT a.title, OR a.title = 'The New Danger'; ``` -### Indentation +### Indentação -To ensure that SQL is readable it is important that standards of indentation -are followed. +Para garantir que o SQL fique legível, é importante que padrões de indentação +sejam seguidos. #### Joins -Joins should be indented to the other side of the river and grouped with a new -line where necessary. +Joins devem ser indentados do outro lado do rio e agrupados com uma nova linha +quando necessário. ```sql SELECT r.last_name @@ -286,10 +284,10 @@ SELECT r.last_name #### Subqueries -Subqueries should also be aligned to the right side of the river and then laid -out using the same style as any other query. Sometimes it will make sense to have -the closing parenthesis on a new line at the same character position as it's -opening partner—this is especially true where you have nested subqueries. +Subqueries também devem ser alinhadas do lado direito do rio e então seguir o +mesmo estilo de qualquer outra query. As vezes faz sentido ter o parêntese de +fechamento em uma nova linha na mesma posição que o parêntese de abertura foi +definido—isso é especialmente importante onde você tem subqueries aninhadas. ```sql SELECT r.last_name, @@ -305,16 +303,16 @@ SELECT r.last_name, AND c.confirmed = 'Y'); ``` -### Preferred formalisms +### Formalismos preferidos -* Make use of `BETWEEN` where possible instead of combining multiple statements - with `AND`. -* Similarly use `IN()` instead of multiple `OR` clauses. -* Where a value needs to be interpreted before leaving the database use the `CASE` - expression. `CASE` statements can be nested to form more complex logical structures. -* Avoid the use of `UNION` clauses and temporary tables where possible. If the - schema can be optimised to remove the reliance on these features then it most - likely should be. +* Faça uso de `BETWEEN` onde possível, ao invés de combinar múltplos `AND`. +* De forma similar, utilize `IN()` ao invés de múltiplas cláusulas `OR`. +* Onde um valor precisa ser interpretado antes de ser retornado pelo banco de + dados, use a expressão `CASE`. Cláusulas `CASE` podem ser aninhadas para formar + estruturas lógicas mais complexas. +* Evite o uso de cláusulas `UNION` e tabelas temporários quando possível. Se + o schema pode ser otimizado, removendo a dependência desses recursos, então + é provável que essa otimização deve ser feita. ```sql SELECT CASE postcode From 413b494f5f06a35bfe43ebe9c7a6460b6bc0e269 Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 11:45:41 -0300 Subject: [PATCH 08/29] Adding Translations - Create syntax - Specifying default values --- _includes/sqlstyle.guide.pt-br.md | 33 ++++++++++++++++--------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index beb357b..fe34370 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -325,28 +325,29 @@ SELECT CASE postcode AND postcode IN ('EH1', 'BN1', 'NN1', 'KW1') ``` -## Create syntax +## Sintaxe Create -When declaring schema information it is also important to maintain human -readable code. To facilitate this ensure the column definitions are ordered and -grouped where it makes sense to do so. +Enquanto declarando informação do schema, é importante manter código legível +por humanos. Para facilitar isso, tenha certeza que as definições das colunas +estão ordenadas e agrupadas onde fizer sentido. -Indent column definitions by four (4) spaces within the `CREATE` definition. +Indente definições de coluna com quatro (4) espaços dentro da definição `CREATE`. -### Choosing data types +### Escolhendo tipos de dados -* Where possible do not use vendor specific data types—these are not portable and - may not be available in older versions of the same vendor's software. -* Only use `REAL` or `FLOAT` types where it is strictly necessary for floating - point mathematics otherwise prefer `NUMERIC` and `DECIMAL` at all times. Floating - point rounding errors are a nuisance! +* Onde possível, não utilize tipos de dados específicos de certos tipos de banco + de dados—eles não são portáteis e podem não estar disponíveis em versões antigas + do mesmo banco de dados. +* Apenas utilize os tipos `REAL` ou `FLOAT` onde é estritamente necessário para + utilizar pontos flutuantes, do contrário prefira sempre `NUMERIC` e `DECIMAL`. + Erros de ponto flutuante são um transtorno! -### Specifying default values +### Especificando valores padrão -* The default value must be the same type as the column—if a column is declared - a `DECIMAL` do not provide an `INTEGER` default value. -* Default values must follow the data type declaration and come before any - `NOT NULL` statement. +* O valor padrão deve ser do mesmo tipo da coluna—se uma coluna foi declarada + como `DECIMAL`, não forcena um `INTEGER` como valor padrão. +* Valores padrão devem seguir a mesma declaração do tipo de dados e vir antes + de qualquer `NOT NULL`. ### Constraints and keys From 88491fedd0fd2de40aac35b3bfb3fdac4e6c1944 Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 13:33:07 -0300 Subject: [PATCH 09/29] Adding Translations - Choosing keys --- _includes/sqlstyle.guide.pt-br.md | 34 +++++++++++++++---------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index fe34370..128198b 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -349,28 +349,28 @@ Indente definições de coluna com quatro (4) espaços dentro da definição `CR * Valores padrão devem seguir a mesma declaração do tipo de dados e vir antes de qualquer `NOT NULL`. -### Constraints and keys +### Constraints e keys -Constraints and their subset, keys, are a very important component of any -database definition. They can quickly become very difficult to read and reason -about though so it is important that a standard set of guidelines are followed. +Constraints e keys são compnentes muito importantes em qualquer definição de +banco de dados. Elas podem rapidamente se tornarem dificeis de se ler e desenvolver +um raciocínio, então é importante seguir um conjunto de diretrizes. -#### Choosing keys +#### Escolhendo keys -Deciding the column(s) that will form the keys in the definition should be a -carefully considered activity as it will effect performance and data integrity. +Deve-se decidir cuidadosamente a(s) coluna(s) que servirão como keys na definição, +já que afetará o desempenho e a integridade dos dados. -1. The key should be unique to some degree. -2. Consistency in terms of data type for the value across the schema and a lower - likelihood of this changing in the future. -3. Can the value be validated against a standard format (such as one published by - ISO)? Encouraging conformity to point 2. -4. Keeping the key as simple as possible whilst not being scared to use compound - keys where necessary. +1. A key deve ser única em algum nível. +2. O tipo de dado para o valor deve ser consistente através do schema e ter + baixa probabilidade de ser alterado no futuro. +3. O valor pode ser validado em relação a um formato padrão (como os publicados + pela ISO)? Incentiva-se a conformidade com o ponto 2. +4. Mantenha a key o mais simples possível, sem medo de utilizar keys compostas + se necessário. -It is a reasoned and considered balancing act to be performed at the definition -of a database. Should requirements evolve in the future it is possible to make -changes to the definitions to keep them up to date. +Tratam-se de atos de equilíbrio a serem efetuados na definição de um banco de +dados. Se os requisitos evoluírem no futuro, é possível fazer alterações nas +definições para mantê-las atualizadas. #### Defining constraints From 49822430eaf786f89d15b72a298bdf240a3dfdcf Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 16:06:23 -0300 Subject: [PATCH 10/29] Adding Translations - Defining constraints - Designs to avoid - Appendix --- _includes/sqlstyle.guide.pt-br.md | 98 ++++++++++++++++--------------- 1 file changed, 50 insertions(+), 48 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 128198b..df0fa9a 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -372,45 +372,47 @@ Tratam-se de atos de equilíbrio a serem efetuados na definição de um banco de dados. Se os requisitos evoluírem no futuro, é possível fazer alterações nas definições para mantê-las atualizadas. -#### Defining constraints +#### Definindo constraints -Once the keys are decided it is possible to define them in the system using -constraints along with field value validation. +Uma vez que as keys foram decididas, é possível definí-las no sistema +utilizando constraints juntamente com validação do valor do campo. -##### General +##### Geral -* Tables must have at least one key to be complete and useful. -* Constraints should be given a custom name excepting `UNIQUE`, `PRIMARY KEY` - and `FOREIGN KEY` where the database vendor will generally supply sufficiently - intelligible names automatically. +* Tabelas precisam ter pelo menos uma key para ser completa e utilizável. +* Constraints devem ter um nome personalizado exceto `UNIQUE`, `PRIMARY KEY` + e `FOREIGN KEY`, onde o fornecedor do banco de dados comumente gera nomes + iteligíveis automaticamente. -##### Layout and order +##### Layout e ordenação -* Specify the primary key first right after the `CREATE TABLE` statement. -* Constraints should be defined directly beneath the column they correspond to. - Indent the constraint so that it aligns to the right of the column name. -* If it is a multi-column constraint then consider putting it as close to both - column definitions as possible and where this is difficult as a last resort - include them at the end of the `CREATE TABLE` definition. -* If it is a table level constraint that applies to the entire table then it - should also appear at the end. -* Use alphabetical order where `ON DELETE` comes before `ON UPDATE`. -* If it make senses to do so align each aspect of the query on the same character - position. For example all `NOT NULL` definitions could start at the same - character position. This is not hard and fast, but it certainly makes the code - much easier to scan and read. +* Especifique a primary key primeiro, logo após a declaração `CREATE TABLE`. +* Constraints devem ser definidas diretamente abaixo da coluna correspondente. + Indente a constraint alinhada à direita do nome da coluna. +* Se é uma constraint que se refere a múltiplas colunas, considere colocá-la + o mais próximo possível a definição das colunas. Se for complicado fazer isso, + como último recurso as inclua no fim da declaração `CREATE TABLE`. +* Se for uma constraint que se aplica a toda a tabela, ela também deve aparecer + no fim. +* Utilize ordem alfabética, onde `ON DELETE` vem antes de `ON UPDATE`. +* Se fizer sentido, alinhe cada aspecto da query na mesma posição de caracteres. + Por exemplo, todas as definições `NOT NULL` poderiam começar na mesma posição + de caracteres. Isso não é difícil nem rápido, mas certamente torna o código + muito mais fácil de se examinar e ler. -##### Validation +##### Validação -* Use `LIKE` and `SIMILAR TO` constraints to ensure the integrity of strings - where the format is known. -* Where the ultimate range of a numerical value is known it must be written as a - range `CHECK()` to prevent incorrect values entering the database or the silent - truncation of data too large to fit the column definition. In the least it - should check that the value is greater than zero in most cases. -* `CHECK()` constraints should be kept in separate clauses to ease debugging. +* Utilize as constraints `LIKE` e `SIMILAR TO` para garantir a integridade de + strings de formato é conhecido. +* Onde a extensão final de um valor numérico é conhecido, é sabido que deve-se + escrever como uma extensão `CHECK()` para evitar que valores incorretos entrem + no banco de dados, ou que o truncamento silencioso dos dados seja muito grande + para ajustar-se ao tamanho definido na coluna. No mínimo, deve-se verificar + na maioria dos casos se o valor é maior que zero. +* Constraints `CHECK()` devem ser mantidas em cláusulas separadas para facilitar + o debugging. -##### Example +##### Exemplo ```sql CREATE TABLE staff ( @@ -423,27 +425,27 @@ CREATE TABLE staff ( ); ``` -### Designs to avoid +### Designs a se evitar -* Object oriented design principles do not effectively translate to relational - database designs—avoid this pitfall. -* Placing the value in one column and the units in another column. The column - should make the units self evident to prevent the requirement to combine - columns again later in the application. Use `CHECK()` to ensure valid data is - inserted into the column. -* [EAV (Entity Attribute Value)][eav] tables—use a specialist product intended for - handling such schema-less data instead. -* Splitting up data that should be in one table across many because of arbitrary - concerns such as time-based archiving or location in a multi-national - organisation. Later queries must then work across multiple tables with `UNION` - rather than just simply querying one table. +* Princípios de design orientado a objetos não se traduzem efetivamente aos designs + de bancos de dados relacionais—evite essa armadilha. +* Colocar o valor em uma coluna e suas unidades em outra coluna. A coluna deve + tornar as unidades evidentes para evitar a necessidade de se combinar colunas + novamente mais tarde na aplicação. Utilize `CHECK()` para garantir que dados + válidos sejam inseridos na coluna. +* Tabelas [EAV (Entity Attribute Value)][eav]—utilize um produto especializado + em para manipular esses dados sem schema. +* Divisão de dados que devem estar em uma tabela em muitas, por preocupações + arbritárias, como arquivamento baseado em tempo ou localização em uma orgnização + multinacional. As consultas posteriores devem trabalhar com múltiplas tabelas + utilizando `UNION` ao invés de simplesmente consultar uma única tabela. +## Apêndice -## Appendix +### Referência de palavras-chave reservadas -### Reserved keyword reference - -A list of ANSI SQL (92, 99 and 2003), MySQL 3 to 5.x, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC and Oracle 10.2 reserved keywords. +Uma lista de palavras-chave reservadas. ANSI SQL (92, 99 and 2003), +MySQL 3 até 5.x, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC e Oracle 10.2. ```sql A From 698b54a41e3dbc4fd04c1823d3813456c9771424 Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 16:11:34 -0300 Subject: [PATCH 11/29] Making translation snippet sounds more natural --- _includes/sqlstyle.guide.pt-br.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index df0fa9a..3d37c7c 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -54,9 +54,9 @@ UPDATE file_system ### Evite -* CamelCase—é dificil para efetuar buscas rapidamente. +* CamelCase—difícil de se analisar rapidamente. * Prefixos descritivos ou notação Húngara como `sp_` ou `tbl`. -* Plurais—utilize um termo coletivo onde possível. Por exemplo, +* Plurais—utilize termos coletivos onde possível. Por exemplo, `pessoal` ao invés de `funcionários` ou `pessoa` no lugar de `indivíduos`. * Identificadores entre aspas—se você precisar utilizá-los, então utilize a as aspas duplas SQL92 por questões de portabilidade (dependendo da desenvolvedora, From 08b1286eff661d3ffabf84fecef4d4e47f9ba0e4 Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 16:14:05 -0300 Subject: [PATCH 12/29] Making translation snippets sounds more natural --- _includes/sqlstyle.guide.pt-br.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 3d37c7c..52f7de4 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -58,9 +58,9 @@ UPDATE file_system * Prefixos descritivos ou notação Húngara como `sp_` ou `tbl`. * Plurais—utilize termos coletivos onde possível. Por exemplo, `pessoal` ao invés de `funcionários` ou `pessoa` no lugar de `indivíduos`. -* Identificadores entre aspas—se você precisar utilizá-los, então utilize a as - aspas duplas SQL92 por questões de portabilidade (dependendo da desenvolvedora, - pode ser necessário configurar seu servidor SQL para suportar isso). +* Identificadores entre aspas—caso necessário, utilize as aspas duplas SQL92 + por questões de portabilidade (dependendo do fornecedor, pode ser necessário + configurar seu servidor SQL para ativar o suporte). * Princípios de design orientado a objetos não devem ser aplicados ao SQL ou a estrutura de bancos de dados. From 552fed2036e4e895e8d1e24324b1e2566df16fd2 Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 16:23:35 -0300 Subject: [PATCH 13/29] fixing typos --- _includes/sqlstyle.guide.pt-br.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 52f7de4..195a7f1 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -3,22 +3,22 @@ ## Visão Geral Você pode utilizar esse conjunto de diretrizes, [fazer um fork][fork] ou criar -seu próprio - a chave é que você selecione um estilo e o siga. Para sugerir +seu próprio - a chave aqui é que você escolha um estilo e o siga. Para sugerir alterações ou correções de bugs, por favor abra uma [issue][issue] ou faça um [pull request][pull] no GitHub. -Essas diretrizes são desenhadas para serem compatíveis com o livro -[SQL Programming Style][celko] de Joe Celko, para ser adotado por times que já -leram o livro mais facilmente. Esse guia é um pouco mais opiniativo em algumas -áreas, enquanto em outras, é mais relaxado. É certamente mais sucinto que -[o livro de Celko][celko], já que ele contém anedotas e racicínios por trás de -cada regra para reflexão. +Essas diretrizes foram desenhadas com compatibilidade com o livro +[SQL Programming Style][celko] de Joe Celko, de forma a ser adotado mais +facilmente por times que já leram o livro. Esse guia é um pouco mais opiniativo +em algumas áreas, e mais relaxado em outras. É certamente mais sucinto que +[o livro de Celko][celko], que contém anedotas e raciocínios por trás de +cada regra. É fácil incluir esse guia com o [formato Markdown][dl-md] como parte do código -base de um projeto, ou referenciá-lo aqui para que qualquer um no projeto possa -ler livremente - muito mais dificil com um livro físico. +base de um projeto ou referenciar aqui, para que qualquer um no projeto possa +ler livremente - algo muito mais dificil com um livro físico. -O Guia De Estilo SQL por [Simon Holywell][simon] é licenciaso sob a +O Guia De Estilo SQL por [Simon Holywell][simon] é licenciado sob a [Creative Commons Attribution-ShareAlike 4.0 International License][licence]. Baseado no trabalho em [http://www.sqlstyle.guide][sqlstyleguide]. @@ -69,13 +69,13 @@ UPDATE file_system ### Geral * Tenha certeza que o nome é único e não existe como uma - [palavra reservada][reserved-keywords]. -* Mantenha o comprimento até um tamanho máximo de 30 bytes-na prática isso são + [palavra-chave reservada][reserved-keywords]. +* Matenha um tamanho máximo de 30 bytes—na prática isso são 30 caracateres, a não ser que você esteja utilizando um conjunto de caracateres multi-byte. * Nomes devem começar com uma letra e não devem terminar com underscore. * Utilize apenas letras, números e underscores em nomes. -* Evite o uso de multiplos underscores consecutivos-eles podem ser dificeis de +* Evite o uso de multiplos underscores consecutivos—eles podem ser dificeis de se ler. * Utilize underscores onde você normalemnte incluiria um espaço no nome (primeiro nome se torna `primeiro_nome`). @@ -115,7 +115,7 @@ SELECT first_name * Como regra geral, o nome da correlação deve ser a primeira letra de cada palavra do nome do objeto. * Se já existe uma correlação com o mesmo nome, acrescente um número. -* Sempre inclua a palavra-chave `AS`-torna mais fácil de ler, pois é explícito. +* Sempre inclua a palavra-chave `AS`—torna mais fácil de ler, pois é explícito. * Para dados computados (`SUM()` ou `AVG()`), utilize o nome que você daria se fosse uma coluna definida no schema. From e23163a97d2bfd10ed9cfb06618d684bdf8a3b1e Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 16:28:59 -0300 Subject: [PATCH 14/29] making translation snippets sounds more natural --- _includes/sqlstyle.guide.pt-br.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 195a7f1..7ffac68 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -27,17 +27,17 @@ Baseado no trabalho em [http://www.sqlstyle.guide][sqlstyleguide]. ### Faça * Utilize identificadores e nomes consistentes e descritivos. -* Faça uso criterioso de espaços em branco e indentação para tornar o código -mais fácil de ler. +* Tenha critério ao utilizar espaços em branco e indentação para melhorar + a legibilidade do código. * Armazene informações de data e hora compatíveis com [ISO-8601][iso-8601] -(`YYYY-MM-DD HH:MM:SS.SSSSS`). + (`YYYY-MM-DD HH:MM:SS.SSSSS`). * Por questões de portabilidade, tente utilizar apenas funções SQL padrão ao -invés de funções específicas de servidores SQL de empresas. -* Mantenha o código sucinto e desprovido de SQL redundante - como adição de -aspas e parênteses desencessários, ou cláusulas WHERE que podem ser derivadas. + invés de funções específicas de servidores SQL de outros fornecedores. +* Mantenha o código sucinto e desprovido de SQL redundante—como adição de aspas + e parênteses desencessários, ou cláusulas WHERE que podem ser derivadas. * Inclua comentários no código SQL quando necessário. Utilize o estilo C abrindo -com `/*` e fechando com `*/` onde possível. Onde não for possível, preceda os -comentários com `--` e termine com uma nova linha. + com `/*` e fechando com `*/` onde possível. Onde não for, preceda os + comentários com `--` e termine com uma nova linha. ```sql SELECT file_hash -- stored ssdeep hash From 05341903bb719250eb79562931966f783dcef2c0 Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 16:32:53 -0300 Subject: [PATCH 15/29] making translation snippets sounds more natural --- _includes/sqlstyle.guide.pt-br.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 7ffac68..153cf82 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -102,10 +102,9 @@ SELECT first_name * Sempre utilize nomes no singular. -* Quando possível, evite simplesmente usar `id` como o identificador primário - da tabela. -* Não adicione uma coluna com o mesmo nome da tabela e vice versa. -* Sempre utilize caixa baixa, exceto onde fizer sentido a sua utilização. +* Quando possível, evite usar apenas `id` como identificador primário da tabela. +* Não adicione uma coluna como o mesmo nome da tabela e vice versa. +* Sempre utilize caixa baixa, exceto onde capitalização fizer sentido. Como em nomes próprios. ### Aliasing ou correlações @@ -115,7 +114,7 @@ SELECT first_name * Como regra geral, o nome da correlação deve ser a primeira letra de cada palavra do nome do objeto. * Se já existe uma correlação com o mesmo nome, acrescente um número. -* Sempre inclua a palavra-chave `AS`—torna mais fácil de ler, pois é explícito. +* Sempre inclua a palavra-chave `AS`—torna o aliasing explícito e mais fácil de ler. * Para dados computados (`SUM()` ou `AVG()`), utilize o nome que você daria se fosse uma coluna definida no schema. From bfe4fccb127de2f796d2053d594fe20c91b86d79 Mon Sep 17 00:00:00 2001 From: Unknown Date: Mon, 17 Apr 2017 23:54:11 -0300 Subject: [PATCH 16/29] Making translation snippet sounds more natural --- _includes/sqlstyle.guide.pt-br.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 153cf82..d007c3a 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -7,16 +7,16 @@ seu próprio - a chave aqui é que você escolha um estilo e o siga. Para sugeri alterações ou correções de bugs, por favor abra uma [issue][issue] ou faça um [pull request][pull] no GitHub. -Essas diretrizes foram desenhadas com compatibilidade com o livro -[SQL Programming Style][celko] de Joe Celko, de forma a ser adotado mais -facilmente por times que já leram o livro. Esse guia é um pouco mais opiniativo -em algumas áreas, e mais relaxado em outras. É certamente mais sucinto que -[o livro de Celko][celko], que contém anedotas e raciocínios por trás de -cada regra. +Essas diretrizes são desenhadas em conformidade com o livro +[SQL Programming Style][celko] de Joe Celko, para ser adotado por times que já +leram o livro mais facilmente. Esse guia é um pouco mais opiniativo em algumas +áreas, enquanto em outras, é mais relaxado. É certamente mais sucinto que +[o livro de Celko][celko], já que ele contém anedotas e racicínios por trás de +cada regra para reflexão. -É fácil incluir esse guia com o [formato Markdown][dl-md] como parte do código -base de um projeto ou referenciar aqui, para que qualquer um no projeto possa -ler livremente - algo muito mais dificil com um livro físico. +É fácil incluir esse guia no [formato Markdown][dl-md] como parte do código +base de um projeto, ou fazer uma referência a esta página para que qualquer um +no projeto possa ler livremente - muito mais dificil com um livro físico. O Guia De Estilo SQL por [Simon Holywell][simon] é licenciado sob a [Creative Commons Attribution-ShareAlike 4.0 International License][licence]. From 5dd0f0ed9b41db21f4b01acde43c7a28b5f0af66 Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 00:25:59 -0300 Subject: [PATCH 17/29] changing translations and fixing typos --- _includes/sqlstyle.guide.pt-br.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index d007c3a..d5a857f 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -3,7 +3,7 @@ ## Visão Geral Você pode utilizar esse conjunto de diretrizes, [fazer um fork][fork] ou criar -seu próprio - a chave aqui é que você escolha um estilo e o siga. Para sugerir +seu próprio - a chave aqui é escolher um estilo e seguir. Para sugerir alterações ou correções de bugs, por favor abra uma [issue][issue] ou faça um [pull request][pull] no GitHub. @@ -68,10 +68,9 @@ UPDATE file_system ### Geral -* Tenha certeza que o nome é único e não existe como uma - [palavra-chave reservada][reserved-keywords]. -* Matenha um tamanho máximo de 30 bytes—na prática isso são - 30 caracateres, a não ser que você esteja utilizando um conjunto de +* Tenha certeza que o nome é único e não é uma [palavra-chave reservada][reserved-keywords]. +* Matenha o tamanho máximo de 30 bytes—na prática isso são + 30 caracateres, a não ser que esteja utilizando um conjunto de caracateres multi-byte. * Nomes devem começar com uma letra e não devem terminar com underscore. * Utilize apenas letras, números e underscores em nomes. @@ -79,7 +78,7 @@ UPDATE file_system se ler. * Utilize underscores onde você normalemnte incluiria um espaço no nome (primeiro nome se torna `primeiro_nome`). -* Evite abreviações. Se você precisar utilizá-las, tenha certeza de que elas +* Evite abreviações. Se precisar utilizá-las, tenha certeza de que elas serão amplamente compreendidas. ```sql From c9bbda08fecec46d004800849f4e531d68c4a789 Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 00:32:23 -0300 Subject: [PATCH 18/29] changing translations and fixing typos --- _includes/sqlstyle.guide.pt-br.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index d5a857f..8ab98c9 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -76,7 +76,7 @@ UPDATE file_system * Utilize apenas letras, números e underscores em nomes. * Evite o uso de multiplos underscores consecutivos—eles podem ser dificeis de se ler. -* Utilize underscores onde você normalemnte incluiria um espaço no nome +* Utilize underscores onde você normalemnte incluiria um espaço (primeiro nome se torna `primeiro_nome`). * Evite abreviações. Se precisar utilizá-las, tenha certeza de que elas serão amplamente compreendidas. @@ -88,10 +88,10 @@ SELECT first_name ### Tabelas -* Utilize um nome coletivo ou de forma menos ideal, uma forma plural. Por exemplo, +* Utilize um nome coletivo ou de forma menos ideal, plurais. Por exemplo, (em ordem de preferência) `pessoal` e `empregados`. * Não utilize prefixos com `tbl` ou qualquer outro prefixo descritivo ou notação - Húngara. + húngara. * Nunca dê a uma tabela o mesmo nome de uma das suas colunas e vice versa. * Evite, quando possível, concatenar dois nomes de tabelas para criar o nome de uma tabela de relacionamento. Ao invés de utilizar `mecanicos_de_carro`, @@ -99,12 +99,11 @@ SELECT first_name ### Colunas - * Sempre utilize nomes no singular. * Quando possível, evite usar apenas `id` como identificador primário da tabela. * Não adicione uma coluna como o mesmo nome da tabela e vice versa. -* Sempre utilize caixa baixa, exceto onde capitalização fizer sentido. - Como em nomes próprios. +* Sempre utilize caixa baixa, exceto onde capitalização fizer sentido, como + em nomes próprios. ### Aliasing ou correlações @@ -113,7 +112,7 @@ SELECT first_name * Como regra geral, o nome da correlação deve ser a primeira letra de cada palavra do nome do objeto. * Se já existe uma correlação com o mesmo nome, acrescente um número. -* Sempre inclua a palavra-chave `AS`—torna o aliasing explícito e mais fácil de ler. +* Sempre inclua a palavra-chave `AS`—isso torna o aliasing explícito e mais fácil de ler. * Para dados computados (`SUM()` ou `AVG()`), utilize o nome que você daria se fosse uma coluna definida no schema. @@ -132,7 +131,7 @@ SELECT SUM(s.monitor_tally) AS monitor_total * O nome deve conter um verbo. * Não adicione `sp_` ou qualquer outro prefixo descritivo ou - notação Húngara. + notação húngara. ### Sufixos uniformes @@ -156,14 +155,14 @@ onde for apropriado. ### Palavras reservadas -Sempre utilize caixa alta para as [palavras-chave reservadas][reserved-keywords] -como `SELECT` e `WHERE` +Sempre utilize caixa alta para [palavras-chave reservadas][reserved-keywords], +como `SELECT` e `WHERE`. É melhor evitar palavras-chave reservadas abreviadas; utilize suas variações com nome completo (use `ABSOLUTE` ao invés de `ABS`). -Não utilize palavras-chave de servidor de banco de dados específico onde é possível -utilizar palavras-chave ANSI SQL já existentes e que tenham a mesma função. +Não utilize palavras-chave de um fornecedor específico de banco de dados +onde for possível utilizar palavras-chave ANSI SQL que tenham a mesma função. Isso ajuda na portabilidade do código. ```sql From 6b4e37f4302155aeb02c492e2e9176782138743a Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 14:12:18 -0300 Subject: [PATCH 19/29] optimizing translation --- _includes/sqlstyle.guide.pt-br.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 8ab98c9..66bd71d 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -1,22 +1,22 @@ -# Guia de Estilo SQL +# Guia de estilo SQL -## Visão Geral +## Visão geral -Você pode utilizar esse conjunto de diretrizes, [fazer um fork][fork] ou criar -seu próprio - a chave aqui é escolher um estilo e seguir. Para sugerir +Você pode utilizar estas diretrizes, [fazer um fork][fork] ou criar +suas próprias - a chave aqui é escolher um estilo e seguir. Para sugerir alterações ou correções de bugs, por favor abra uma [issue][issue] ou faça um [pull request][pull] no GitHub. -Essas diretrizes são desenhadas em conformidade com o livro -[SQL Programming Style][celko] de Joe Celko, para ser adotado por times que já -leram o livro mais facilmente. Esse guia é um pouco mais opiniativo em algumas -áreas, enquanto em outras, é mais relaxado. É certamente mais sucinto que -[o livro de Celko][celko], já que ele contém anedotas e racicínios por trás de -cada regra para reflexão. +Estas diretrizes foram desenhadas em conformidade com o livro +[SQL Programming Style][celko] de Joe Celko, para serem adotadas mais facilmente +por equipes que já leram o livro. Em relação ao livro, este guia é um pouco mais +opiniativo em algumas áreas, enquanto em outras, é mais relaxado. É certamente +mais sucinto que [o livro de Celko][celko], que contém anedotas e racicínios por +trás de cada regra. É fácil incluir esse guia no [formato Markdown][dl-md] como parte do código base de um projeto, ou fazer uma referência a esta página para que qualquer um -no projeto possa ler livremente - muito mais dificil com um livro físico. +no projeto possa ler livremente. O Guia De Estilo SQL por [Simon Holywell][simon] é licenciado sob a [Creative Commons Attribution-ShareAlike 4.0 International License][licence]. From e88a310d5715ebe0f896f78c9ab91dc5cc012ce0 Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 14:52:19 -0300 Subject: [PATCH 20/29] optimizing translation --- _includes/sqlstyle.guide.pt-br.md | 99 +++++++++++++++---------------- 1 file changed, 49 insertions(+), 50 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 66bd71d..9606abe 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -10,7 +10,7 @@ alterações ou correções de bugs, por favor abra uma [issue][issue] ou faça Estas diretrizes foram desenhadas em conformidade com o livro [SQL Programming Style][celko] de Joe Celko, para serem adotadas mais facilmente por equipes que já leram o livro. Em relação ao livro, este guia é um pouco mais -opiniativo em algumas áreas, enquanto em outras, é mais relaxado. É certamente +opiniativo em algumas áreas e mais tranquilo em outras. Certamente é mais sucinto que [o livro de Celko][celko], que contém anedotas e racicínios por trás de cada regra. @@ -31,10 +31,10 @@ Baseado no trabalho em [http://www.sqlstyle.guide][sqlstyleguide]. a legibilidade do código. * Armazene informações de data e hora compatíveis com [ISO-8601][iso-8601] (`YYYY-MM-DD HH:MM:SS.SSSSS`). -* Por questões de portabilidade, tente utilizar apenas funções SQL padrão ao - invés de funções específicas de servidores SQL de outros fornecedores. +* Por questões de portabilidade, tente utilizar apenas funções SQL padrão no lugar + de funções específicas de servidores SQL de fornecedores. * Mantenha o código sucinto e desprovido de SQL redundante—como adição de aspas - e parênteses desencessários, ou cláusulas WHERE que podem ser derivadas. + e parênteses desnecessários, ou cláusulas WHERE que podem ser derivadas. * Inclua comentários no código SQL quando necessário. Utilize o estilo C abrindo com `/*` e fechando com `*/` onde possível. Onde não for, preceda os comentários com `--` e termine com uma nova linha. @@ -55,7 +55,7 @@ UPDATE file_system ### Evite * CamelCase—difícil de se analisar rapidamente. -* Prefixos descritivos ou notação Húngara como `sp_` ou `tbl`. +* Prefixos descritivos ou notação húngara como `sp_` ou `tbl`. * Plurais—utilize termos coletivos onde possível. Por exemplo, `pessoal` ao invés de `funcionários` ou `pessoa` no lugar de `indivíduos`. * Identificadores entre aspas—caso necessário, utilize as aspas duplas SQL92 @@ -69,7 +69,7 @@ UPDATE file_system ### Geral * Tenha certeza que o nome é único e não é uma [palavra-chave reservada][reserved-keywords]. -* Matenha o tamanho máximo de 30 bytes—na prática isso são +* Matenha o tamanho máximo em 30 bytes—na prática isso são 30 caracateres, a não ser que esteja utilizando um conjunto de caracateres multi-byte. * Nomes devem começar com uma letra e não devem terminar com underscore. @@ -78,8 +78,8 @@ UPDATE file_system se ler. * Utilize underscores onde você normalemnte incluiria um espaço (primeiro nome se torna `primeiro_nome`). -* Evite abreviações. Se precisar utilizá-las, tenha certeza de que elas - serão amplamente compreendidas. +* Evite abreviações. Se precisar utilizá-las, tenha certeza de que serão + amplamente compreendidas. ```sql SELECT first_name @@ -88,13 +88,13 @@ SELECT first_name ### Tabelas -* Utilize um nome coletivo ou de forma menos ideal, plurais. Por exemplo, +* Utilize um nome coletivo ou menos idealmente, plurais. Por exemplo, (em ordem de preferência) `pessoal` e `empregados`. * Não utilize prefixos com `tbl` ou qualquer outro prefixo descritivo ou notação húngara. * Nunca dê a uma tabela o mesmo nome de uma das suas colunas e vice versa. -* Evite, quando possível, concatenar dois nomes de tabelas para criar o nome de - uma tabela de relacionamento. Ao invés de utilizar `mecanicos_de_carro`, +* Evite quando possível concatenar dois nomes de tabelas para criar o nome de + uma tabela de relacionamento. No lugar de `mecanicos_de_carro`, prefira `servicos`. ### Colunas @@ -102,8 +102,8 @@ SELECT first_name * Sempre utilize nomes no singular. * Quando possível, evite usar apenas `id` como identificador primário da tabela. * Não adicione uma coluna como o mesmo nome da tabela e vice versa. -* Sempre utilize caixa baixa, exceto onde capitalização fizer sentido, como - em nomes próprios. +* Sempre utilize caixa baixa, exceto onde capitalização fizer sentido (como + em nomes próprios). ### Aliasing ou correlações @@ -158,11 +158,11 @@ onde for apropriado. Sempre utilize caixa alta para [palavras-chave reservadas][reserved-keywords], como `SELECT` e `WHERE`. -É melhor evitar palavras-chave reservadas abreviadas; utilize suas variações com -nome completo (use `ABSOLUTE` ao invés de `ABS`). +É melhor evitar palavras-chave abreviadas; utilize suas variações por extenso +(use `ABSOLUTE` ao invés de `ABS`). -Não utilize palavras-chave de um fornecedor específico de banco de dados -onde for possível utilizar palavras-chave ANSI SQL que tenham a mesma função. +Não utilize palavras-chave de um fornecedor específico de banco de dados. Onde for +possível, utilize palavras-chave reservadas ANSI SQL que tenham a mesma função. Isso ajuda na portabilidade do código. ```sql @@ -173,16 +173,15 @@ SELECT model_num ### Espaços em branco -Para tornar o código mais fácil de ler, é importante que o cumprimento correto -de espaçamento esteja sendo utilizado. Não coloque código ou remova espaços -naturais da linguagem. +Para tornar o código mais fácil de ler, é importante o uso correto do espaçamento. +Não insira código ou remova espaços em linguagem natural. #### Espaços Espaços devem ser utilizados para alinhar o código, de forma que as palavras-chave -terminem sempre no mesmo limite de caracteres. Isso forma um rio tipográfico, -tornando fácil bater olho, visualizar o código e separar as palavras-chave dos -detalhes de implementação. Rios são [ruins na tipografia][rivers], mas úteis aqui. +fiquem sempre no mesmo limite. Isso forma um rio tipográfico, tornando fácil visualizar +o código e separar as palavras-chave dos detalhes de implementação. +Rios são [ruins na tipografia][rivers], mas úteis aqui. ```sql (SELECT f.species_name, @@ -204,15 +203,15 @@ detalhes de implementação. Rios são [ruins na tipografia][rivers], mas úteis GROUP BY b.species_name, b.observation_date) ``` -Note que o `SELECT`, `FROM`, etc. estão todos a direita, alinhados, enquanto -os nomes das colunas em si e os detalhes específicos de implementação estão -alinhados à esquerda. +Note que o `SELECT`, `FROM`, etc. estão todos alinhados à direita, enquanto +os nomes das colunas em si e os detalhes de implementação estão alinhados à +esquerda. Sempre inclua espaços: -* antes de depois do símbolo igual (`=`) +* antes e depois do símbolo igual (`=`) * depois de vírgulas (`,`) -* ao redor de apóstrofes (`'`) caso não estejam entre parênteses, com uma vírgula +* ao redor de apóstrofes (`'`) caso não estejam entre parênteses ou com uma vírgula ou ponto e vírgula. ```sql @@ -227,15 +226,15 @@ SELECT a.title, a.release_date, a.recording_date Sempre inclua novas linhas/espaço vertical: * antes de `AND` ou `OR` -* depois de vírgulas, separando as queries para uma leitura mais fácil +* depois de vírgulas, separando as queries para facilitar a leitura * depois de cada definição de palavras-chave * depois de um ponto, quando seperando múltiplas colunas em grupos lógicos * para separar código em seções relacionadas, o que ajuda na legibilidade de grandes pedaços de código. -Manter todas as palavras-chave alinhadas ao lado direito e os valores alinhados -ao lado esquerdo, cria uma lacuna no meio da query. Isso torna muito mais fácil -e rápido a análise da definição da query. +Manter todas as palavras-chave alinhadas à direita e os valores alinhados +à esqueda cria uma lacuna no meio da query. Isso torna a análise da definição +da query mais fácil e rápida. ```sql INSERT INTO albums (title, release_date, recording_date) @@ -259,13 +258,13 @@ SELECT a.title, ### Indentação -Para garantir que o SQL fique legível, é importante que padrões de indentação +Para garantir que o SQL seja legível, é importante que padrões de indentação sejam seguidos. #### Joins -Joins devem ser indentados do outro lado do rio e agrupados com uma nova linha -quando necessário. +Joins devem ser indentados do outro lado do rio tipográfico e agrupados +com uma nova linha quando necessário. ```sql SELECT r.last_name @@ -281,10 +280,10 @@ SELECT r.last_name #### Subqueries -Subqueries também devem ser alinhadas do lado direito do rio e então seguir o -mesmo estilo de qualquer outra query. As vezes faz sentido ter o parêntese de -fechamento em uma nova linha na mesma posição que o parêntese de abertura foi -definido—isso é especialmente importante onde você tem subqueries aninhadas. +Subqueries também devem ser alinhadas à direita do rio e seguir o mesmo estilo +de qualquer outra query. As vezes faz sentido ter o parêntese de fechamento em +uma nova linha na mesma posição que o parêntese de abertura foi definido—isso é +especialmente importante onde você tem subqueries aninhadas. ```sql SELECT r.last_name, @@ -307,9 +306,9 @@ SELECT r.last_name, * Onde um valor precisa ser interpretado antes de ser retornado pelo banco de dados, use a expressão `CASE`. Cláusulas `CASE` podem ser aninhadas para formar estruturas lógicas mais complexas. -* Evite o uso de cláusulas `UNION` e tabelas temporários quando possível. Se - o schema pode ser otimizado, removendo a dependência desses recursos, então - é provável que essa otimização deve ser feita. +* Evite o uso de cláusulas `UNION` e tabelas temporárias quando possível. Se + o schema pode ser otimizado removendo a dependência desses recursos, é melhor + otimizar. ```sql SELECT CASE postcode @@ -324,19 +323,19 @@ SELECT CASE postcode ## Sintaxe Create -Enquanto declarando informação do schema, é importante manter código legível -por humanos. Para facilitar isso, tenha certeza que as definições das colunas -estão ordenadas e agrupadas onde fizer sentido. +Enquanto declarando informação do schema, é importante manter um código humanamente +legível. Para garantir isso, assegure-se de que as definições das colunas estejam +ordenadas e agrupadas onde fizer sentido. Indente definições de coluna com quatro (4) espaços dentro da definição `CREATE`. ### Escolhendo tipos de dados -* Onde possível, não utilize tipos de dados específicos de certos tipos de banco - de dados—eles não são portáteis e podem não estar disponíveis em versões antigas - do mesmo banco de dados. -* Apenas utilize os tipos `REAL` ou `FLOAT` onde é estritamente necessário para - utilizar pontos flutuantes, do contrário prefira sempre `NUMERIC` e `DECIMAL`. +* Onde possível, não utilize tipos de dados específicos de fornecedores de banco + de dados—esses formatos geralmente não são portáteis e podem estar indisponíveis + em versões antigas do banco de dados do mesmo fornecedor. +* Utilize os tipos `REAL` ou `FLOAT` apenas onde o uso de pontos flutuantes for + estritamente necessário, do contrário prefira sempre `NUMERIC` e `DECIMAL`. Erros de ponto flutuante são um transtorno! ### Especificando valores padrão From 205d74d6c565807927170c5b2d5e4aac180c2c10 Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 15:14:29 -0300 Subject: [PATCH 21/29] Fixing Typos --- _includes/sqlstyle.guide.pt-br.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 9606abe..b91f05b 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -10,8 +10,8 @@ alterações ou correções de bugs, por favor abra uma [issue][issue] ou faça Estas diretrizes foram desenhadas em conformidade com o livro [SQL Programming Style][celko] de Joe Celko, para serem adotadas mais facilmente por equipes que já leram o livro. Em relação ao livro, este guia é um pouco mais -opiniativo em algumas áreas e mais tranquilo em outras. Certamente é -mais sucinto que [o livro de Celko][celko], que contém anedotas e racicínios por +opinativo em algumas áreas e mais tranquilo em outras. Certamente é +mais sucinto que [o livro de Celko][celko], que contém anedotas e raciocínios por trás de cada regra. É fácil incluir esse guia no [formato Markdown][dl-md] como parte do código @@ -69,12 +69,12 @@ UPDATE file_system ### Geral * Tenha certeza que o nome é único e não é uma [palavra-chave reservada][reserved-keywords]. -* Matenha o tamanho máximo em 30 bytes—na prática isso são +* Mantenha o tamanho máximo em 30 bytes—na prática isso são 30 caracateres, a não ser que esteja utilizando um conjunto de caracateres multi-byte. * Nomes devem começar com uma letra e não devem terminar com underscore. * Utilize apenas letras, números e underscores em nomes. -* Evite o uso de multiplos underscores consecutivos—eles podem ser dificeis de +* Evite o uso de múltiplos underscores consecutivos—eles podem ser difíceis de se ler. * Utilize underscores onde você normalemnte incluiria um espaço (primeiro nome se torna `primeiro_nome`). @@ -136,7 +136,7 @@ SELECT SUM(s.monitor_tally) AS monitor_total ### Sufixos uniformes Os sufixos seguintes tem sentido universal, garantindo que as colunas possam ser -lidas e compreendedidas facilmente no código SQL. Utilize os sufixos corretos +lidas e compreendidas facilmente no código SQL. Utilize os sufixos corretos onde for apropriado. * `_id`—um identificador único, como uma coluna que é a chave primária. @@ -228,12 +228,12 @@ Sempre inclua novas linhas/espaço vertical: * antes de `AND` ou `OR` * depois de vírgulas, separando as queries para facilitar a leitura * depois de cada definição de palavras-chave -* depois de um ponto, quando seperando múltiplas colunas em grupos lógicos +* depois de um ponto, quando separando múltiplas colunas em grupos lógicos * para separar código em seções relacionadas, o que ajuda na legibilidade de grandes pedaços de código. Manter todas as palavras-chave alinhadas à direita e os valores alinhados -à esqueda cria uma lacuna no meio da query. Isso torna a análise da definição +à esquerda cria uma lacuna no meio da query. Isso torna a análise da definição da query mais fácil e rápida. ```sql @@ -301,7 +301,7 @@ SELECT r.last_name, ### Formalismos preferidos -* Faça uso de `BETWEEN` onde possível, ao invés de combinar múltplos `AND`. +* Faça uso de `BETWEEN` onde possível, ao invés de combinar múltiplos `AND`. * De forma similar, utilize `IN()` ao invés de múltiplas cláusulas `OR`. * Onde um valor precisa ser interpretado antes de ser retornado pelo banco de dados, use a expressão `CASE`. Cláusulas `CASE` podem ser aninhadas para formar @@ -341,14 +341,14 @@ Indente definições de coluna com quatro (4) espaços dentro da definição `CR ### Especificando valores padrão * O valor padrão deve ser do mesmo tipo da coluna—se uma coluna foi declarada - como `DECIMAL`, não forcena um `INTEGER` como valor padrão. + como `DECIMAL`, não force um `INTEGER` como valor padrão. * Valores padrão devem seguir a mesma declaração do tipo de dados e vir antes de qualquer `NOT NULL`. ### Constraints e keys -Constraints e keys são compnentes muito importantes em qualquer definição de -banco de dados. Elas podem rapidamente se tornarem dificeis de se ler e desenvolver +Constraints e keys são componentes muito importantes em qualquer definição de +banco de dados. Elas podem rapidamente se tornarem difíceis de se ler e desenvolver um raciocínio, então é importante seguir um conjunto de diretrizes. #### Escolhendo keys @@ -370,7 +370,7 @@ definições para mantê-las atualizadas. #### Definindo constraints -Uma vez que as keys foram decididas, é possível definí-las no sistema +Uma vez que as keys foram decididas, é possível defini-las no sistema utilizando constraints juntamente com validação do valor do campo. ##### Geral @@ -432,7 +432,7 @@ CREATE TABLE staff ( * Tabelas [EAV (Entity Attribute Value)][eav]—utilize um produto especializado em para manipular esses dados sem schema. * Divisão de dados que devem estar em uma tabela em muitas, por preocupações - arbritárias, como arquivamento baseado em tempo ou localização em uma orgnização + arbitrárias, como arquivamento baseado em tempo ou localização em uma organização multinacional. As consultas posteriores devem trabalhar com múltiplas tabelas utilizando `UNION` ao invés de simplesmente consultar uma única tabela. From 7517edf055ee1beab8aec0a4ef811249ea63e2ed Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 15:27:29 -0300 Subject: [PATCH 22/29] optimizing translations --- _includes/sqlstyle.guide.pt-br.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index b91f05b..14f35a8 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -347,13 +347,13 @@ Indente definições de coluna com quatro (4) espaços dentro da definição `CR ### Constraints e keys -Constraints e keys são componentes muito importantes em qualquer definição de -banco de dados. Elas podem rapidamente se tornarem difíceis de se ler e desenvolver -um raciocínio, então é importante seguir um conjunto de diretrizes. +Constraints e keys são componentes muito importantes na definição de qualquer +banco de dados. Elas podem se tornar difíceis de ler e desenvolver raciocínios, +por isso é importante também seguir um conjunto de diretrizes. #### Escolhendo keys -Deve-se decidir cuidadosamente a(s) coluna(s) que servirão como keys na definição, +Deve-se decidir cuidadosamente na definição a(s) coluna(s) que serão keys, já que afetará o desempenho e a integridade dos dados. 1. A key deve ser única em algum nível. @@ -361,11 +361,11 @@ já que afetará o desempenho e a integridade dos dados. baixa probabilidade de ser alterado no futuro. 3. O valor pode ser validado em relação a um formato padrão (como os publicados pela ISO)? Incentiva-se a conformidade com o ponto 2. -4. Mantenha a key o mais simples possível, sem medo de utilizar keys compostas +4. Mantenha a key o mais simples possível, não tenha medo de utilizar keys compostas se necessário. -Tratam-se de atos de equilíbrio a serem efetuados na definição de um banco de -dados. Se os requisitos evoluírem no futuro, é possível fazer alterações nas +Trata-se de um ato de equilíbrio a ser feito na definição de um banco de dados. +Se os requisitos evoluírem no futuro, será possível fazer alterações nas definições para mantê-las atualizadas. #### Definindo constraints From 47ee87f8939ee0187fcf9123f998fc1ef14dfb0e Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 15:32:07 -0300 Subject: [PATCH 23/29] optimizing translations --- _includes/sqlstyle.guide.pt-br.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 14f35a8..ba59e9b 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -375,31 +375,30 @@ utilizando constraints juntamente com validação do valor do campo. ##### Geral -* Tabelas precisam ter pelo menos uma key para ser completa e utilizável. -* Constraints devem ter um nome personalizado exceto `UNIQUE`, `PRIMARY KEY` +* Tabelas precisam ter pelo menos uma key para serem completas e utilizáveis. +* Constraints devem ter um nome personalizado exceto por `UNIQUE`, `PRIMARY KEY` e `FOREIGN KEY`, onde o fornecedor do banco de dados comumente gera nomes - iteligíveis automaticamente. + inteligíveis automaticamente. ##### Layout e ordenação * Especifique a primary key primeiro, logo após a declaração `CREATE TABLE`. * Constraints devem ser definidas diretamente abaixo da coluna correspondente. - Indente a constraint alinhada à direita do nome da coluna. + Indente a constraint alinhando à direita do nome da coluna. * Se é uma constraint que se refere a múltiplas colunas, considere colocá-la - o mais próximo possível a definição das colunas. Se for complicado fazer isso, + o mais próximo possível à definição das colunas. Se for complicado fazer isso, como último recurso as inclua no fim da declaração `CREATE TABLE`. * Se for uma constraint que se aplica a toda a tabela, ela também deve aparecer no fim. * Utilize ordem alfabética, onde `ON DELETE` vem antes de `ON UPDATE`. * Se fizer sentido, alinhe cada aspecto da query na mesma posição de caracteres. - Por exemplo, todas as definições `NOT NULL` poderiam começar na mesma posição - de caracteres. Isso não é difícil nem rápido, mas certamente torna o código - muito mais fácil de se examinar e ler. + Por exemplo, todas as definições `NOT NULL` podem começar verticalmente alinhadas. + Pode dar trabalho, mas torna o código muito mais fácil de se examinar e ler. ##### Validação * Utilize as constraints `LIKE` e `SIMILAR TO` para garantir a integridade de - strings de formato é conhecido. + strings que tenham formato conhecido. * Onde a extensão final de um valor numérico é conhecido, é sabido que deve-se escrever como uma extensão `CHECK()` para evitar que valores incorretos entrem no banco de dados, ou que o truncamento silencioso dos dados seja muito grande From e99c5d04ac48a79d59861d15d6a1f1283ab1cea9 Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 16:14:09 -0300 Subject: [PATCH 24/29] optimizing translations --- _includes/sqlstyle.guide.pt-br.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index ba59e9b..783398f 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -399,11 +399,9 @@ utilizando constraints juntamente com validação do valor do campo. * Utilize as constraints `LIKE` e `SIMILAR TO` para garantir a integridade de strings que tenham formato conhecido. -* Onde a extensão final de um valor numérico é conhecido, é sabido que deve-se - escrever como uma extensão `CHECK()` para evitar que valores incorretos entrem - no banco de dados, ou que o truncamento silencioso dos dados seja muito grande - para ajustar-se ao tamanho definido na coluna. No mínimo, deve-se verificar - na maioria dos casos se o valor é maior que zero. +* Onde a extensão final de um valor numérico é conhecida, deve-se utilizar + `CHECK()` para evitar que valores incorretos sejam inseridos no banco de dados, + ou que o truncamento silencioso dos dados seja muito grande para caber no tamanho definido na coluna. No mínimo, deve-se verificar na maioria dos casos se o valor é maior que zero. * Constraints `CHECK()` devem ser mantidas em cláusulas separadas para facilitar o debugging. @@ -422,7 +420,7 @@ CREATE TABLE staff ( ### Designs a se evitar -* Princípios de design orientado a objetos não se traduzem efetivamente aos designs +* Princípios de design orientado a objetos não se traduzem efetivamente ao design de bancos de dados relacionais—evite essa armadilha. * Colocar o valor em uma coluna e suas unidades em outra coluna. A coluna deve tornar as unidades evidentes para evitar a necessidade de se combinar colunas @@ -430,10 +428,9 @@ CREATE TABLE staff ( válidos sejam inseridos na coluna. * Tabelas [EAV (Entity Attribute Value)][eav]—utilize um produto especializado em para manipular esses dados sem schema. -* Divisão de dados que devem estar em uma tabela em muitas, por preocupações - arbitrárias, como arquivamento baseado em tempo ou localização em uma organização - multinacional. As consultas posteriores devem trabalhar com múltiplas tabelas - utilizando `UNION` ao invés de simplesmente consultar uma única tabela. +* Divisão de dados que devem estar em uma tabela em muitas, por questões + arbitrárias como arquivamento baseado em tempo ou localização em uma organização + multinacional. De forma que consultas posteriores devam trabalhar com múltiplas tabelas utilizando `UNION` ao invés de simplesmente consultar uma única tabela. ## Apêndice From bedb4fed90e874dfec483bdfed2abef391ec8941 Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 16:40:11 -0300 Subject: [PATCH 25/29] adding index.md file --- pt-BR/index.md | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 pt-BR/index.md diff --git a/pt-BR/index.md b/pt-BR/index.md new file mode 100644 index 0000000..8b13423 --- /dev/null +++ b/pt-BR/index.md @@ -0,0 +1,10 @@ +--- +layout: default +lang: pt-BR +lang_title: Guia de Estilo SQL +--- + +* TOC +{:toc} + +{% include sqlstyle.guide.pt-BR.md %} From b718ec9272ae073a192af1d353be5a96847abcaf Mon Sep 17 00:00:00 2001 From: Marcus Pereira Date: Tue, 18 Apr 2017 16:42:29 -0300 Subject: [PATCH 26/29] Rename sqlstyle.guide.pt-br.md to sqlstyle.guide.pt-BR.md --- _includes/{sqlstyle.guide.pt-br.md => sqlstyle.guide.pt-BR.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename _includes/{sqlstyle.guide.pt-br.md => sqlstyle.guide.pt-BR.md} (100%) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-BR.md similarity index 100% rename from _includes/sqlstyle.guide.pt-br.md rename to _includes/sqlstyle.guide.pt-BR.md From d8d8182c848d785ea40b8cf35d21ba74614ce3de Mon Sep 17 00:00:00 2001 From: Marcus Pereira Date: Tue, 18 Apr 2017 16:45:27 -0300 Subject: [PATCH 27/29] Update sqlstyle.guide.pt-BR.md optimizing translation --- _includes/sqlstyle.guide.pt-BR.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/_includes/sqlstyle.guide.pt-BR.md b/_includes/sqlstyle.guide.pt-BR.md index 783398f..9cbeab8 100644 --- a/_includes/sqlstyle.guide.pt-BR.md +++ b/_includes/sqlstyle.guide.pt-BR.md @@ -430,7 +430,8 @@ CREATE TABLE staff ( em para manipular esses dados sem schema. * Divisão de dados que devem estar em uma tabela em muitas, por questões arbitrárias como arquivamento baseado em tempo ou localização em uma organização - multinacional. De forma que consultas posteriores devam trabalhar com múltiplas tabelas utilizando `UNION` ao invés de simplesmente consultar uma única tabela. + multinacional. Assim, consultas posteriores deverão trabalhar com múltiplas tabelas + utilizando `UNION` ao invés consultar apenas uma única tabela. ## Apêndice From 94e55434cae6900ffcab436afdfcd211c9a0598b Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 18:55:36 -0300 Subject: [PATCH 28/29] optimizing translations --- _includes/sqlstyle.guide.pt-BR.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/_includes/sqlstyle.guide.pt-BR.md b/_includes/sqlstyle.guide.pt-BR.md index 9cbeab8..ea25ad5 100644 --- a/_includes/sqlstyle.guide.pt-BR.md +++ b/_includes/sqlstyle.guide.pt-BR.md @@ -401,7 +401,9 @@ utilizando constraints juntamente com validação do valor do campo. strings que tenham formato conhecido. * Onde a extensão final de um valor numérico é conhecida, deve-se utilizar `CHECK()` para evitar que valores incorretos sejam inseridos no banco de dados, - ou que o truncamento silencioso dos dados seja muito grande para caber no tamanho definido na coluna. No mínimo, deve-se verificar na maioria dos casos se o valor é maior que zero. + ou que o truncamento silencioso dos dados seja muito grande para caber no tamanho + definido na coluna. No mínimo, deve-se verificar na maioria dos casos se o valor + é maior que zero. * Constraints `CHECK()` devem ser mantidas em cláusulas separadas para facilitar o debugging. From 60ceff0778e05dc6aa3b899bf79c3fbd6c98bb43 Mon Sep 17 00:00:00 2001 From: Simon Holywell Date: Wed, 19 Apr 2017 10:18:11 +1000 Subject: [PATCH 29/29] Add links to the pt-BR translation --- README.md | 1 + _includes/foot.html | 4 ++++ _includes/head.html | 8 ++++++-- _includes/sqlstyle.guide.pt-BR.md | 4 ++-- _layouts/default.html | 1 + {pt-BR => pt-br}/index.md | 0 6 files changed, 14 insertions(+), 4 deletions(-) rename {pt-BR => pt-br}/index.md (100%) diff --git a/README.md b/README.md index 287fc62..2e85947 100644 --- a/README.md +++ b/README.md @@ -27,6 +27,7 @@ If you would like to translate the guide then please open a pull request or open if you need some help getting it setup. * [Japanese/日本語](http://www.sqlstyle.guide/ja/) by [nkurigit](https://github.com/nkurigit) +* [Portuguese (Brazil)/Português (BR)](http://www.sqlstyle.guide/pt-br/) by [pmarcus93](https://github.com/pmarcus93) * [Simplified Chinese/简体中文](http://www.sqlstyle.guide/zh/) by [wontoncoder](https://github.com/wontoncoder) diff --git a/_includes/foot.html b/_includes/foot.html index 09d1602..ac41272 100644 --- a/_includes/foot.html +++ b/_includes/foot.html @@ -10,6 +10,10 @@ 日本語 · + + Português (BR) + + · 简体中文 diff --git a/_includes/head.html b/_includes/head.html index 834111f..007713c 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -8,11 +8,15 @@ English · - + 日本語 · - + + Português (BR) + + · + 简体中文 diff --git a/_includes/sqlstyle.guide.pt-BR.md b/_includes/sqlstyle.guide.pt-BR.md index ea25ad5..cd95a90 100644 --- a/_includes/sqlstyle.guide.pt-BR.md +++ b/_includes/sqlstyle.guide.pt-BR.md @@ -1280,7 +1280,7 @@ ZONE "SQL style guide pull requests on GitHub" [celko]: https://www.amazon.com/gp/product/0120887975/ref=as_li_ss_tl?ie=UTF8&linkCode=ll1&tag=treffynnon-20&linkId=9c88eac8cd420e979675c815771313d5 "Joe Celko's SQL Programming Style (The Morgan Kaufmann Series in Data Management Systems)" -[dl-md]: https://raw.githubusercontent.com/treffynnon/sqlstyle.guide/gh-pages/_includes/sqlstyle.guide.md +[dl-md]: https://raw.githubusercontent.com/treffynnon/sqlstyle.guide/gh-pages/_includes/sqlstyle.guide.pt-BR.md "Download the guide in Markdown format" [iso-8601]: https://en.wikipedia.org/wiki/ISO_8601 "Wikipedia: ISO 8601" @@ -1292,5 +1292,5 @@ ZONE "Wikipedia: Entity–attribute–value model" [sqlstyleguide]: http://www.sqlstyle.guide "SQL style guide by Simon Holywell" -[licence]: http://creativecommons.org/licenses/by-sa/4.0/ +[licence]: https://creativecommons.org/licenses/by-sa/4.0/deed.pt_BR "Creative Commons Attribution-ShareAlike 4.0 International License" diff --git a/_layouts/default.html b/_layouts/default.html index 24981c8..fbe03dd 100644 --- a/_layouts/default.html +++ b/_layouts/default.html @@ -34,6 +34,7 @@ + diff --git a/pt-BR/index.md b/pt-br/index.md similarity index 100% rename from pt-BR/index.md rename to pt-br/index.md