Por que os programadores ignorariam os padrões ISO? [fechadas]


18

Uma das coisas pelas quais me deparo com frequência são os problemas causados ​​por programas que não estão em conformidade com os padrões ISO.

Um exemplo seria não usar as tabelas ISO dos países, mas criar suas próprias taquigrafia, o que dá certo para os Estados Unidos (EUA) ou a Holanda (NL), mas dá espetacularmente errado para o Reino Unido (GB, não o Reino Unido) ou a Espanha (ES, não SP) e muitos outros países.

Como outro exemplo, notações internas de data. Por que alguém armazenaria uma data como 01/02/2014? Não está totalmente claro se isso é 1º de fevereiro ou 2 de janeiro, enquanto que se você usar o padrão ISO, basta armazenar 2014-02-01 * e é inequivocamente 1º de fevereiro.

Minha pergunta: quando e por que um programador deve criar suas próprias construções quando existe um padrão ISO disponível?

* Armazene 01-02-2014 e formate a data adequadamente ao mostrá-la a um usuário final.


64
Porque eles não os conhecem ou se esqueceram deles! Existem gazilhões de padrões ISO .... Você conhece todo o ISO26262?
Basile Starynkevitch

11
Geralmente, a falta de experiência como programador faz com que você faça coisas das quais não percebe quais são as consequências. Geralmente, um rápido "eu vou fazer assim" é pensado instantaneamente, sem qualquer avaliação sobre se já existe algo para ele ou não.
dammkewl

13
Além disso, muitos padrões ISO não são fáceis de encontrar (geralmente custam muito dinheiro, e encontrar o rascunho mais recente não é tão fácil!).
Basile Starynkevitch

64
A grande vantagem dos padrões é que existem tantos por onde escolher!
Jörg W Mittag

5
Entre as coisas mais estranhas, estão os programas que forçam um usuário local não inglês a alterar as configurações locais do sistema para pontos decimais, a fim de funcionar corretamente. Para não falar de programas que se recusam a trabalhar ou simplesmente produzem lixo sob conjuntos de caracteres não ingleses (russo, japonês, grego), muito menos em sistemas RTL (hebraico, árabe). Há alguma ignorância envolvida, eu acho.
JensG

Respostas:


63

Nunca atribua à malícia aquilo que é adequadamente explicado pela estupidez. - Robert J. Hanlon .

Isso e falta de comunicação.

Portanto, não é uma conspiração de sentimentos anti-ISO que faz as pessoas pensarem "eu sei, usarei o Reino Unido em vez de GB", nem é uma tendência que "elas saibam melhor", ou mesmo uma sensação de que o padrão não seja bom . Será inteiramente porque eles simplesmente não sabem que existe e devem usá-lo.

Quero dizer, para algumas pessoas, se não estiver incluído no Visual Studio , é possível que não exista. Para outros, talvez eles simplesmente não desejem o conjunto completo ou seja muito difícil buscar a lista definitiva, então eles apenas formam seu próprio subconjunto para resolver sua situação imediata. Para outros, o padrão é o que é usado. Portanto, a formatação da data não é "formatada em ISO, ou mesmo localidade do país", é "formatada no que for necessário" e, se isso for adequado, o trabalho será feito (geralmente é um críticas de programadores americanos).


20
Não ajuda que muitos padrões ISO sejam caros e / ou difíceis de obter ... Mesmo que você queira!
22814 heltonbiker

aaaa-mm-dd ... não é caro
halfbit

11
@ Halfbit: Caro para comprar, não caro em recursos computacionais. Sério, procure sua loja . Você quer o padrão de ponto flutuante ? São 178 francos.
User2357112 suporta Monica

32

Quando programa em Ruby, geralmente sempre ignoro o padrão ISO Ruby. Por quê? Porque é incrivelmente restritivo! O ISO Ruby é um subconjunto mínimo da interseção do Ruby 1.8 e Ruby 1.9. A versão atual do Ruby, suportada por todas as implementações do Ruby (ou pelo menos será muito em breve) é Ruby 2.1, e possui muitos recursos que facilitam a programação. A programação no ISO Ruby é uma PITA.

Quando programa em C #, também ignoro o ISO C #, que é um subconjunto do C # 2.0 (e, mais importante, a ISO Class Library é um subconjunto extremamente pequeno do .NET BCL.) Em vez disso, programa em C # 5.0 e não me restrito a usar apenas as bibliotecas especificadas na ISO CLI; em vez disso, uso o subconjunto comum de bibliotecas disponíveis no .NET 4.5.2 e Mono 3.4.0.

E, ao fazer web design, prefiro usar HTML5 sobre HTML HTML (que é um pequeno subconjunto do HTML 4.01 Strict), novamente, porque o HTML5 é muito mais rico em recursos do que um subconjunto restrito de uma versão antiga do HTML.

Portanto, existem boas razões para ignorar os padrões ISO.


9
Depende, com C, C ++, Fortran ... a situação é muito diferente.
Vladimir F

1
Isso parece menos com "ignorar", como a pergunta pretende, e mais com "escolher uma ferramenta que faça o que você precisa". Se você precisar dos recursos do C # 5.0, não faz mais sentido usar o ISO C # do que usaria o ISO C ou o ISO Fortran; simplesmente não é a ferramenta que você solicitou e a ISO não tem um equivalente. Seu exemplo também envolve a aderência a padrões bem definidos, mas não os ISO.
21814 Leushenko

3
@Leushenko eu discordo; o OP parece pensar que você deve sempre seguir os padrões ISO, ponto final. +1 para um contraexemplo descarado deste "deveria".
22414 djechlin

3
Tudo bem, mas acho que a questão estava realmente falando sobre os padrões ISO para representação de dados, não os padrões ISO para linguagens de programação.
Aaronaught

4
Alguns argumentam que (alguns) Normas ISO são um exemplo perfeito do "Design by Comissão" anti-padrão ...
heltonbiker

22

Por seu exemplo, "GB" é o código do país para o Reino Unido. No entanto, "Reino Unido" foi o código padrão do MARC (Biblioteca do Congresso dos EUA), embora eu acredite que isso seja preterido. E a IANA usa .ukpara o domínio de nível superior do Reino Unido.

Portanto, se algo não estiver em conformidade com um padrão ISO, isso não significa que nenhum padrão esteja sendo usado; pode simplesmente significar que um padrão diferente está sendo usado. (Como @ Jörg observou em um comentário, a coisa boa sobre os padrões é que existem tantos por onde escolher.) Nesse caso, a pergunta realmente se torna qual padrão seria o mais apropriado para o domínio, ambiente etc. do problema em questão ?

As respostas a essa pergunta provavelmente seriam amplamente baseadas em opiniões e rapidamente degenerariam em um debate "religioso". Mas a conformidade com o padrão ISO nem sempre é a melhor resposta. Por exemplo, se um software precisar fazer interface com os bancos de dados da biblioteca, os padrões MARC poderão ser uma escolha mais apropriada que a ISO. Se a maioria dos softwares da sua organização faz as coisas de uma certa maneira, você pode seguir essa abordagem, pelo menos a curto prazo - afinal, é o "padrão" da sua organização.


Além disso, os padrões evoluem / mudam. O que foi conforme ontem pode não ser hoje.


E, embora eu não queira excluir a ignorância e / ou a preguiça como a causa dos problemas que você aponta ... o desenvolvedor pode simplesmente não ter tido tempo suficiente para resolvê-los.


15

A conformidade com um padrão ISO nem sempre é uma atividade gratuita. Se um padrão específico ainda não foi implementado no kit de ferramentas que ela está usando, o programador se depara com uma opção necessária: é mais barato implementá-lo corretamente agora ou não implementar o padrão e lidar com as conversões posteriormente?

É fácil dizer "ei, você sempre deve implementar o padrão", mas tudo tem um custo. E há algumas boas razões pelas quais um programador pode não querer implementar um padrão ISO.

  • O cliente pode estar seguindo um padrão proprietário ou não ISO. É melhor seguir o padrão que um cliente espera do que deixar dores de cabeça não intencionais para o seu sucessor, ocultando uma implementação adicional além do que o cliente deseja e do seu idioma exige.
  • Pode haver uma grande quantidade de dados existentes e uma conversão ou quebra de formato ainda não é viável. Se você tiver vinte anos de contatos e contratos de clientes com datas locais, não necessariamente desejará alterar todas essas centenas de milhões de campos para datas padrão ISO até que você possa fazer o que é certo.
  • A adesão ao padrão pode impor um custo maior do que o benefício oferece. Se você estiver lidando com entradas inteiramente nos Estados Unidos, por exemplo, o código ISO-3166-2 de cinco caracteres (US-NY) terá três caracteres desnecessários sobre o código postal padrão dos EUA (NY).

1
Processos ágeis à parte, é sempre mais barato incluir qualquer recurso - incluindo um padrão ISO - durante a fase de design / especificação do que durante a fase de implementação / manutenção, porque a fase de design representa apenas 10% do trabalho. Isso é apenas uma inversão da lei dos retornos decrescentes - semelhante à maneira como identificar e corrigir um defeito na produção pode custar até 10x mais do que se fosse encontrado como resultado de um teste de unidade ou de aceitação. Se você tem um motivo sólido para não usar o padrão ISO , tudo bem; se você diz que vai implementá-lo mais tarde, está mentindo.
Aaronaught

@Aaronaught: Você acha que eu deveria esclarecer que por "conversão" eu quis dizer uma conversão de arquivo externo, em vez de uma reescrita interna?
DougM

Se é isso que você quis dizer, certamente eu esclareceria. Normalmente, não é tão simples, pois a ISO define mais padrões para tipos de dados que tipos de arquivo, e muitos, se não a maioria, desenvolvedores lidam com aplicativos que não lidam com documentos ou "arquivos" por si só. Se, por exemplo, você armazena uma data ou código de país que não seja ISO em um banco de dados (e não armazena a data ou código de país ISO correspondente), o custo da conversão no futuro será muito alto. Por outro lado, se você está simplesmente falando sobre a importação de algum tipo de arquivo específico do setor, certamente pode fazer isso sempre.
Aaronaught

+1 "... você não quer necessariamente alterar todas essas centenas de milhões de campos ... até conseguir fazer o que é certo." Exatamente.
David

14

No caso de programadores / designers de banco de dados inexperientes , é por não saber. Eles tendem a reinventar a roda porque não conhecem um grupo de pessoas de todas as indústrias, já discutiram o assunto e criaram um padrão aprovado por todos os que participaram, geralmente após longas discussões, revisões, etc. Recentemente, um colega de trabalho um dos meus demonstrou incredulidade quando lhe disse que havia um padrão ISO sobre se uma determinada semana é considerada a última semana de um ano ou a primeira do ano seguinte ( ISO 8601 ). Ele não acreditava que existia um padrão em relação a algo tão específico. Eu disse a ele que a correção de muitos aplicativos dependia desse padrão.

No caso de programadores experientes / designers de banco de dados , isso é desconsiderado por "conhecer melhor" , síndrome não inventada aqui e / ou grandiosidade. Eles não confiam na ISO ou em qualquer outro organismo padrão porque consideram que o código ISO "não é suficientemente estável" , o que significa que um dia será alterado. Portanto, eles criam códigos / identificadores próprios, inventados aqui ou com incremento automático, dificultando a interoperabilidade, o que também desconsideram. Veja esta pergunta semelhante , ainda que inclusa no design do banco de dados. Eles dão razões como:

Talvez eu não queira necessariamente que meu design de banco de dados dependa de vários terceiros (IATA, ISO), independentemente de quão estáveis ​​sejam seus padrões. Ou talvez eu não queira depender de um padrão específico.

insira a descrição da imagem aqui

Curiosamente, aqueles que desconsideram os padrões usam portas USB padrão, compram DVDs e BluRays de tamanho padrão e dirigem carros com pneus que cumprem os padrões.


12
-1 para sua caricatura de programadores anti-ISO experientes.
22414 djechlin

4
@djechlin As frases entre aspas são literais de respostas reais na pergunta vinculada. Você pode até pesquisar na página para ver essas opiniões reais. Também nem todos os programadores experientes odeiam padrões.
Tulains Córdova

2
@ djechlin Na minha resposta, há uma pergunta vinculada, procure "veja esta pergunta semelhante". A palavra "pergunta" tem um link. Lá você pode procurar as frases exatas entre aspas.
Tulains Córdova

2
@djechlin o link está na resposta, não a pergunta, aqui está: programmers.stackexchange.com/questions/204340/...
Tulains Córdova

5
Por outro lado, a pessoa que escreveu esta resposta está deturpando a questão vinculada; o problema não era com as pessoas que não queriam usar os padrões, mas com a dependência da estabilidade de um padrão em particular como chave primária . Atualmente, os designers de banco de dados mais experientes tentarão desviá-lo das "chaves naturais", ponto final, porque quase inevitavelmente se tornam menos naturais do que você imaginava inicialmente. Isso é simplesmente um argumento para dissociar o design do banco de dados físico dos dados lógicos - ninguém disse para não usar os padrões.
Aaronaught

10

Bem, as pessoas tendem a ignorar os padrões ISO: por exemplo, você escreveu

se você usar o padrão ISO, basta armazenar 20140201 * e é inequivocamente 1º de fevereiro.

mas a versão totalmente compatível com ISO8601 é de fato 01/02/2014 . (veja também xkcd 1179 )


7
O padrão ISO8601 permite os formatos AAAA-MM-DD e AAAAMMDD para representações completas da data do calendário.
Pieter B

1
De fato; daí a minha escrita "totalmente compatível". 20140201 é o formato "básico" no padrão.
Clément

8
A ISO permite o formato básico e estendido, ambos são totalmente compatíveis.
Pieter B

10
ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04.clássico
WernerCD

8

Um dos motivos é que o domínio do aplicativo e os usuários podem não usar esses padrões. Mesmo quando alguns domínios usam alguns padrões, alguns deles podem ter feito escolhas diferentes dos padrões ISO, geralmente por razões históricas.

Se seus usuários já usam "UK" em seus procedimentos existentes (1) para se referir a "Reino Unido da Grã-Bretanha e Irlanda do Norte", não faz sentido usar "GB" em suas estruturas de dados (especialmente se você significa que país não é um país "ISO", por exemplo, separando nações do Reino Unido ou tendo diferenças sutis com as Ilhas do Canal e assim por diante). Obviamente, você pode ter um mapeamento entre o armazenamento interno e uma apresentação, mas às vezes é um pouco exagerado. Você raramente está programando para programar, geralmente precisa se adaptar ao seu ambiente. 2)

Você também deve se lembrar que esses padrões evoluíram em paralelo com o software. Você geralmente precisa desenvolver no contexto de outras partes de software, algumas das quais podem ser projetadas de maneira imperfeita, algumas das quais ainda podem ser afetadas por decisões herdadas.

Mesmo se você olhar para os formatos internos de armazenamento de dados, é difícil resolver algumas ambiguidades. Por exemplo, até onde eu sei, o Excel usa um número decimal para representar registros de data e hora: usa um número inteiro como o número de dias desde a data de referência; depois, o que é depois do decimal representa a fração das 24 horas para fornecer a hora. .. O problema é que isso impede que você leve em consideração os fusos horários ou o horário de verão (23h ou 25h em um dia), e o Excel converte qualquer data / hora para esse formato interno por padrão. Se você deseja usar o formato ISO ou não, torna-se irrelevante se outro software com o qual você tiver que trabalhar não lhe deixar uma escolha.

(1) Não quero dizer "procedimentos de programação" aqui.

(2) Não me pergunte por que as pessoas também não usam esses padrões em suas vidas diárias. Quero dizer YYYYmmdd é claro, dd / mm / YYYY é claro, mas ordenar uma data com média, pequena e grande ordem de granularidade como mm / dd / YYYY, isso simplesmente não faz sentido :-).


1
Ha! Você sabe o que não faz sentido? Vírgulas onde os decimais devem estar! ;)
Darkwater23

@ Darkwater23 Há, eu não me importo com isso de qualquer maneira, é apenas uma convenção e não precisa fazer sentido. É que eu sempre achei que mm / dd / AAAA parecia não ter lógica, por que não ir até mm-MM-dd-HH-AAAA para timestamps ;-) Mas ei, eu concordo, é exatamente assim é, então temos que viver com isso.
257 Bruno

2
@ Darkwater23 Na verdade, um padrão ISO usa um símbolo unicode estranho (isto :) para separador decimal em teclados , e eu pensei que marcas de escala simples ( ') também eram padronizadas para agrupamento de dígitos (embora eu não possa encontrá-lo agora)
Izkata

+1 por apontar outro motivo pelo qual o horário de verão é uma perda de tempo.
CTRL-ALT-DELOR

1
@richard Eu não me importo necessariamente com o horário de verão, mas certamente os programadores devem tentar armazenar seus carimbos de data e hora com informações de fuso horário o máximo possível. De qualquer forma, não é incomum que um aplicativo seja usado em vários fusos horários (independentemente do horário de verão), certifique-se de deixar pouco espaço para ambiguidade ao armazenar um carimbo de data / hora deve fazer parte do design inicial. (Pode não ser sempre aplicável, mas na dúvida, sempre vale a pena levar em consideração.) É claro que é um problema complicado (não apenas +01 hora, por exemplo, mas a localidade também pode ser importante, dependendo do uso).
267 Bruno

8

Por que eu não usaria os códigos de país ISO 3166-1 alfa-2 ?

Porque eu uso o STANAG 1059 códigos de país ... e nesse Reino Unido é o código para o Reino Unido (em vez de GB conforme ISO 3166-1).

Como alternativa, eu poderia usar o códigos de país FIPS - novamente o Reino Unido é o código de país do Reino Unido.

Existem muitos padrões (ISO e não ISO) e, às vezes, um domínio específico usa / exige um padrão que é incompatível com o padrão ISO.


7

Armazenar 20140201 não é nada ambíguo. Somente quando você inclui o conhecimento que está seguindo o padrão ISO, ele se torna inequívoco. O mesmo vale para 01/02/2014: quando você inclui o conhecimento de que o formato é mm / dd / aaaa, também é perfeitamente inequívoco.

Desde que o aplicativo não precise interagir com outro aplicativo, qualquer padrão bem documentado pode funcionar tão bem.

Há uma troca entre o que é fácil para humanos (eu costumo usar 1-2-2014) e computadores (quem seria melhor com uma representação binária em vez de ISO). Programadores iniciantes tendem a seguir o que conseguem entender com facilidade, mais experiências programadores começam a ver as vantagens do armazenamento orientado por computador.


4
Acordado. Eu ficaria mais preocupado com a ISO se estivesse escrevendo um pedido de consumo internacional. Meus aplicativos para a América Central não precisam de sobrecarga ou restrições.
precisa

4
Ao escrever "Contanto que o aplicativo não precise interagir com outro aplicativo", você deu um forte motivo para usar o padrão ISO.
Tulains Córdova

5
Seu perfil não lista sua localização, por isso não sei se a data da sua amostra é em janeiro ou fevereiro.
22414 djechlin

6
-1 por assumir que não fará interface com outros aplicativos. Isso é contrário a toda a indústria de programação.
22414 djechlin

18
@ Jeff: Eu nunca vi uma data codificada como YYYYDDMM para qualquer outra finalidade que não seja a de que tal codificação seja possível. Você já?
Supercat

5

Um ponto não levantado até o momento é a adequação cultural dos padrões internacionais.

Considere o padrão internacional para medições. Vamos apresentá-los a usuários nos Estados Unidos. Não sei se todos os seus usuários nos EUA ficarão felizes com quilômetros, quilogramas e litros.

Considere que os padrões internacionais são escritos pelos governos. Se o governo da Espanha optar por não reconhecer o idioma basco, como obtém uma especificação ISO? Isso é particularmente um problema com os dialetos e crioulos de grupos marginalizados.

Até os códigos dos países podem ser problemáticos: a Criméia agora tem seu próprio código? Eventualmente, são encontradas fórmulas (por exemplo, "Antiga República Jugoslava da Macedônia"), mas seu aplicativo pode precisar de algum apoio até que a diplomacia ou a guerra termine.

Considere que os padrões internacionais são escritos com aplicativos específicos em mente. Isso pode não ser totalmente adequado ao seu aplicativo. Por exemplo, se você estiver armazenando um idioma com o objetivo de enviar cartas, convém codificar os cegos de maneira distinta, mesmo que eles sejam proficientes em falar, por exemplo, inglês dos EUA. As organizações de estatística estão bem cientes da necessidade de especificar o significado exato de uma variável (também conhecido como "metadados") da variável, pois encontram todos os possíveis casos extremos durante um censo populacional. Parte desse rigor vale a pena para os campos do banco de dados.

O ponto final é que, ao fazer esse tipo de escolha, seu programa pode estar fazendo uma declaração política. Essa realidade pode mexer com o melhor código (por exemplo, você pode precisar de vários nomes de idioma para o mesmo idioma).


Acredito que a maioria das pessoas cegas seria capaz de conseguir que alguém lesse uma carta para elas. Não é como se você fosse a primeira pessoa (ou empresa) a enviar uma carta a eles.
Curinga

5

Na minha experiência, os programadores falham em usar os padrões ISO por várias razões declaradas, por exemplo:

  • "Eu não sabia que havia um padrão ISO" (deixa de ser um motivo válido quando você é avisado!)
  • "O padrão está inacessível (não é possível encontrar / comprar uma cópia)" (realmente?)
  • "O padrão é muito restritivo" (geralmente se o padrão diz "não", existe um bom motivo. Ignore-o por sua conta e risco do seu cliente!)
  • "O padrão não inclui a funcionalidade / biblioteca mais recente" (nenhum padrão inclui TODAS as bibliotecas que você desejará usar, portanto siga o padrão para as coisas que inclui / cubra e seja consistente com o padrão para as coisas que não)
  • "O padrão é muito pesado para implementar" (desculpa muito usada, mas veja abaixo)

A única razão que aceito da minha equipe, por não ser uma desculpa esfarrapada, é "o padrão realmente não é um bom 'ajuste'" - apoiado em evidências. Às vezes, a complexidade do padrão ISO aplicável é desproporcional ao problema / solução. Às vezes, o contexto em que você implementará sua solução é significativamente diferente daquele assumido pelo padrão. E, às vezes, o padrão pode ser aprimorado - é assim que o progresso acontece.

Mais frequentemente, porém, a falha no uso do padrão ISO pode ser atribuída à inexperiência, preguiça ou arrogância. Lamento dizer que os programadores de língua inglesa são particularmente culpados de preguiça em relação à internacionalização e que nossos colegas dos EUA tendem a perceber a ISO como "uma coisa europeia irrelevante" (desculpas à minoria a quem isso não se aplica).


5
Não é necessariamente algo europeu irrelevante, é irrelevante, a menos que você precise interagir com alguém que os siga. Com que frequência os europeus seguem os padrões ANSI sem outra razão além de parecerem um padrão?
stonemetal

1

A ISO tem muitos padrões. Como fez o CCITT / ITU. Alguns desses padrões são "aspiracionais", enquanto outros são a funcionalidade mínima exigida. Muitas vezes não é claro qual é qual.

Lembro-me dos anos 80 perguntando por que alguns fornecedores de equipamentos implementam um subconjunto do padrão, enquanto outros fornecedores implementam um subconjunto diferente. Foi quando saiu que os padrões são frequentemente definidos antes que algo funcione. E os fornecedores geralmente escolhem deliberadamente não implementar padrões para prejudicar a interoperabilidade, o que lhes concede uma vantagem.

É por isso que eu gosto de RFCs da IETF. Eles nem se tornam RFCs até que haja três implementações independentes do RFC.


2
O modelo de "consenso aproximado e código de execução" da IETF foi bem abandonado desde pelo menos desde 1995. Eu estava muito envolvido na IETF naquela época e o modelo era "uma especificação que eu espirrei e nem mesmo uma implementação de referência " Foi bom quando o padrão "código em execução" estava em vigor, em vez de descobrir como implementar um protocolo totalmente subespecificado e fazê-lo funcionar com outras implementações que precisavam adivinhar tanto quanto você.
25414 java #

1
Quando comecei a usar RFCs do IETF, usei os desenvolvidos antes de 1995. As especificações de código em execução são as melhores. Caso contrário, você acabará com muitos engenheiros de gráficos de torre de marfim imaginando especificações sem a responsabilidade de fazê-las funcionar.
22814 Jay Godse

1

Se estou construindo um banco de dados Oracle e quero armazenar datas, vou usar o tipo de dados Oracle DATE. Não saberei nem me importarei se a Oracle está ou não em conformidade com o padrão ISO. Este é realmente um caso de minha conformidade com um padrão diferente (o Oracle) e não muito diferente do padrão ISO. Veja a resposta de @ David.

Em alguns casos, quando percebi que havia um padrão ISO para algo que eu havia projetado, o custo de voltar e redesenhar seria proibitivo ou, pelo menos, era visto dessa maneira.

No curto prazo, mais código de trabalho é produzido usando os padrões disponíveis ou inventando novos do que com uma pesquisa cuidadosa sobre os padrões existentes. A desvantagem ocorre quando a integração em grande escala requer interoperabilidade. Isso quase sempre ocorre no contexto de um projeto posterior.


1
Não estou familiarizado com o Oracle, mas ao usar o SQL Server ou o MySQL, é claro que também uso os respectivos tipos de dados de data para armazenar datas. Mas, ao escrever consultas com datas, os dois reconhecem aaaammdd muito bem onde é um erro ou um acerto quando você usa uma data de localidade.
Pieter B

Este é um bom ponto. O padrão para o armazenamento e o padrão para a interface podem ser diferentes.
Walter Mitty
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.