A velocidade de envio é diretamente proporcional à qualidade da estrutura de dados, especialmente na era em que a interface do utilizador pode ser cada vez mais tratada como um ativo efémero. Mais pragmaticamente, isso inclui: - o tipo de loja que você usa, por exemplo, relacional, gráfico, etc. - a forma como você estrutura seus dados em entidades e relacionamentos - a forma como você captura informações, por exemplo, você pode querer armazenar um status como um booleano (por exemplo, is_disabled) ou pode optar por inferir essa informação a partir de um timestamp (por exemplo, disabled_at), ambos têm prós e contras - a forma como você conecta conjuntos de dados entre plataformas, por exemplo, banco de dados, armazenamento, logs, etc. - a forma como você estrutura sua API, constrói consultas e consome dados Ser data-first é um código de trapaça para aumentar sua velocidade de envio. Más decisões de dados podem ser extremamente dolorosas de desfazer e, quando você começa a vê-las claramente, nunca pode voltar atrás.
dennis
dennis5/07/2025
quanto mais eu projeto/construo, mais percebo: uma estrutura de dados errada é como uma linha de cabelo em recessão. estás arruinado. tentar disfarçar só piora a situação conversei com outros fundadores que concordaram que a estrutura de dados é trabalho do CEO. todo engenheiro sabe que deve evitar migrações sempre que possível. um lugar fácil para estragar a interface é a tabela de contas. isso leva empresas escaladas +6 meses para corrigir. quase certo de que a ramp/linear navega rápido porque cometeram menos erros aqui.
51,44K