Início / dba / Perguntas / 266795
Accepted
Vivek Jha
Asked: 2020-05-09 15:32:26 +0800 CST

Scripting a configuração de um banco de dados MySQL - melhores práticas?

  • 772

Eu sou um novato em administração de banco de dados. Estou configurando meu primeiro banco de dados no meu localhost no MySQL e quero entender as melhores práticas. Este é o meu fluxo de trabalho atual:

# do_everything.sql

SELECT 'CREATING DATABASE STRUCTURE' info;

DROP DATABASE IF EXISTS my_first_db;
CREATE DATABASE IF NOT EXISTS my_first_db;
USE my_first_db;

SET default_storage_engine = innodb;
SELECT CONCAT('storage engine: ', @@default_storage_engine) info;

SELECT 'CREATING TABLE A' info;
-- Code to create table from source_data_A.csv

SELECT 'CREATING LOGGER FOR TABLE A' info;
-- Code to create log table for table A
-- Code to create insert, update, & delete triggers for table A

SELECT 'LOADING SOURCE DATA A' info;
-- Code to load source_data_A.csv into table A

SELECT 'CREATING TABLE B' info;
-- Code to create table from source_data_B.csv

SELECT 'CREATING LOGGER FOR TABLE B' info;
-- Code to create log table for table B
-- Code to create insert, update, & delete triggers for table B

SELECT 'LOADING SOURCE DATA B' info;
-- Code to load source_data_B.csv into table B

SELECT 'DATABASE CREATION COMPLETE' info;

No meu Terminal, eu executo:

mysql --local-infile=1 -uroot -p < /absolute/path/to/do_everything.sql

  1. Devo dividir do_everything.sqlem arquivos diferentes .sqlde acordo com pedaços lógicos? Em caso afirmativo, eu teria um único script de shell mestre que executasse todos eles?

  2. Se eu mantiver o mesmo fluxo de trabalho, estou seguindo as práticas recomendadas?

database-design mysql-8.0

1 respostas

  1. Best Answer
    • Should I be splitting up do_everything.sql into different .sql files according to logical chunks? If so, would I then have a single master shell script that executes all of them?

    IMHO, sim, você deve dividir seu do_everything.sqlscript em pedaços lógicos menores - a modularização é uma das principais ferramentas que nós, engenheiros de software, temos à nossa disposição para ajudar a organizar nosso trabalho, e isso levará a menos bugs e menos erros. Você pode testar módulo por módulo em vez de ter que sempre lidar com um gigante (ou "juggernaut" como alguém do subcontinente indiano pode dizer! :-) ).

    • If I keep the same workflow, am I following best practices?

    Veja minhas observações sobre modularização acima - acredito que seria considerado uma prática recomendada dividir seu script em partes lógicas - eu costumava sempre fazê-lo tabela por tabela - dessa forma era fácil ver onde surgiam os problemas e o " sub-scripts" podem ser testados um por um ou o script mestre pode ser verificado.

    Você perguntou nos comentários:

    • Can I modularize the scripts and run them from a single "master" .sql file? If so, having trouble looking up the command to do so.

    É muito simples - você simplesmente usa a palavra- SOURCEchave (ie SOURCE /path/to/file.sql) em seus scripts - você pode aninhar isso em muitos níveis (mas não muitos).

    O que eu normalmente fazia era ter um master_script.sql que na verdade era apenas um "esqueleto" - era apenas preenchido com SOURCEinstruções chamando outros scripts. Alguns deles podem ter SOURCEdeclarações ( dentro da razão ). Achei isso funcionou muito bem.

    • 1

relate perguntas