| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | O MySQL já suporta subselect's e regras de integridade?
KISS - Keep It Simple, Stupid! |
| |
| |
| | http://www.mysql.com/products/mysql/index.html
Expanded support for subqueries
Subqueries allow you to use the result of one query as a component of a larger query. The MySQL server already supports some forms of this technique, such as INSERT INTO ... SELECT ..., and this support will be expanded in version 4.1 to include nested SELECT queries, which is one of the most-requested features from our users.
Stored procedures and triggers
Stored procedures allow you to create functions and subroutines that run on the server. This makes it possible to grant access to specific queries without granting carte blanche access to the underlying data, or validate data in the database before it is stored. Triggers can be configured to fire when certain conditions are fulfilled. The MySQL database server will provide hooks for implementing stored procedures in multiple languages, as well as including support for the Persistent Stored Modules syntax defined as part of ANSI SQL-99. Support for stored procedures and triggers will be introduced in version 5.0.
Comentários:
subselects - quem é que precisa disto ...
regras de integridade - innodb tables acid compliance
trigers e stored procedures - remeter para a resposta a subselects
Razão pelo Mysql ser a DB preferida: velocidade
|
| |
| | [...] and this support will be expanded in version 4.1 to include nested SELECT queries, which is one of the most-requested features from our users.
subselects - quem é que precisa disto...
Um bocado contraditório, não?
KISS - Keep It Simple, Stupid! |
| |
| | realmente, mas será que custa muito fazer dois selects em vez de um grande?
|
| |
| | A questão não é o de custar muito ou não, mas é uma função que um SGDB *deve* ter. SELECT * from EMAIL where address NOT IN (SELECT address from SPAM_EMAIL); Podes fazer isto assim ou então podes inventar uma maneira mais xpto de o fazer (e podes ter o azar de fazer algo não-standard que depois não corre em mais nenhum SGBD).
KISS - Keep It Simple, Stupid! |
| |
| | The queries:
SELECT * FROM table1 WHERE id NOT IN (SELECT id FROM table2);
SELECT * FROM table1 WHERE NOT EXISTS (SELECT id FROM table2
WHERE table1.id=table2.id);
Can be rewritten as:
SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
WHERE table2.id IS NULL;
Using a LEFT [OUTER] JOIN is generally much faster than an equivalent subquery because the server can optimise it better, a fact that is not specific to MySQL Server alone. Prior to SQL-92, outer joins did not exist, so subqueries were the only way to do certain things in those bygone days. But that is no longer the case, MySQL Server and many other modern database systems offer a whole range of outer joins types.
For more complicated subqueries you can often create temporary tables to hold the subquery. In some cases, however, this option will not work. The most frequently encountered of these cases arises with DELETE statements, for which standard SQL does not support joins (except in subqueries). For this situation there are three options available:
The first option is to upgrade to MySQL version 4.1.
The second option is to use a procedural programming language (such as Perl or PHP) to submit a SELECT query to obtain the primary keys for the records to be deleted, and then use these values to construct the DELETE statement (DELETE FROM ... WHERE ... IN (key1, key2, ...)).
Normalmente usa-se a segunda opção, dois queries usando a linguagem com que estamos a programar.
|
| |
| | 1º: Essa query do "not in" pode redundar num grande disparate pois não está relacionada com a de fora. E como não tem condições traz todos os registos e varre toda a tabela... e depois mete isso num espaço temporário. Um verdadeiro "must" se a tabela "de dentro" fôr grandita ;)
Por isso usem sempre a 2ª alternativa (caso não usem o left join)
2º: Há como eles dizem casos mais complexos. Ocorre-me um em que existem vários registos do mesmo "objecto" com datas diferentes e queres só o mais recente - MAX(data_ocorrencia). Mas acredito que se consiga contornar...
3º A sugestão de contornar com a linguagem... pois é giro... dá muito mais trabalho... ah... e convém ter transacções, o que obriga no mySQL a ter certos tipos de tabelas... os tais "alíenigenas" que falei noutro post. Ah... e claro... entre obter os registos e apagá-los eles podem mudar de estado... Há que pôr novamente condições no delete para além do ID... e se calhar ficamos novamente na mesma... Ou então bloqueamo-los na leitura, mas não sei se o mySQL suporta isso... enfim... gosto bué >:>
Cumprimentos
|
| |
| | A resposta a "quem é que precisa de sub-queries" é dada por eles ao dizerem que é a caracteristica mais pedida. E respondendo a um post mais à frente, por vezes não é uma questão de escrever dois selects. Pensa em sub-selects co-relacionados.
Regras de integridade são suportadas num tipo de tabelas "alíenigena" ao mySQL...
Triggers e SP... bem, qualquer pessoa que queira fazer algo complexo com uma BD considera isto fundamental.
mySQL é rápido? Óptimo... alguma coisa de bom havia de ter... claro que as outras seriam mais rápidas se não fizessem metade das coisas que fazem...:)
Sim, é verdade... não gramo mySQL. Nunca usei nenhuma BD "free". Mas pelo que leio não usaria mySQL. Acredito no entanto que se adapte bem a ambientes Web.
Cumprimentos.
|
| |
| | Acredito no entanto que se adapte bem a ambientes Web.
Existe a tendência para querer comparar o MySQL a outros RDBMSs mais "a sério" como o PostgreSQL o que não é uma comparação própriamente válida. O MySQL está realmente apontado ao ambiente Web onde a performance é mais importante e onde a falta de certas funcionalidades é, na maior parte dos casos, pouco relevante. O dia em que o MySQL suportar todas as funcionalidades que hoje estão disponíveis no PostgreSQL (por exemplo) será o dia em que deixará de ter vantagem na Web. Este facto relativamente óbvio é a razão porque o SAP-DB vai mudar de nome (MaxSQL) e passar a ser gerido, em parte, pela MySQL AB.
-- Carlos Rodrigues
|
| |
| | O MaxSQL é um derivado de MySQL, não da SAPDB.
Fonte
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| Nope (Pontos:3, Esclarecedor) |
| | | |
| | MaxSQL != MaxDB ;)
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
|
| | Favorite Backup Utility: TAR, interessante muito usado, mas e a poderosa aplicação Mondo???
|
| |
| | Tou confuso... o que é suposto ser isto?
"Favorite Desktop Workstation: HOMEMADE"
É Homemade (aplicação) ou homemade (feito em casa/customizado à medida)?
|
| |
| |
| | Feito em casa... Uma Desktop Workstation é um computador.
[] |
| |
| | | é o que cá se chama linha branca.. compras os componentes na xafarica do amigo que até te vende a preço de revenda.. montas o pc rulante em casa.. abres um granda buraco de lado e metes uma tonelada de ventoinhas.. claro que o belo do neon é um must.. et voila.. tens um desktop home made.. geek mais geek não ha Vx
|
| |
| | pelo nono ano seguinte fomos roubados...
|
| |
| |
| | Aposto que o Major Valentim meteu a mão no concurso!! :-)
--
"Muda, que quando a gente muda, o Mundo muda com a gente" -- Gabriel, o Pensador |
| |
| | Favorite Programming Language: C++
Favorite Text Editor: VIM
Hereges!!
-- Carlos Rodrigues
|
| |
| |
| | Joe forever! :)
"It is every citizen's final duty to go into the tanks and become one with all the people."
- Chairman Sheng-ji Yang, "Ethics for Tomorrow" |
| |
| | | Que tal?
Com um especial destaque para o software com suporte para portugues... Seria uma referência interessante para o pessoal em portugal (empresas, admin. pública, whatever) que procura justificar mudanças para Linux... non?
|
| |
| | Se tivermos em conta a má reputacao da rackspace em relacao ao spam, e' surpreendente que pessoas informadas (o caso geral dos utilizadores de Linux, espero eu) a escolham como empresa de hosting.
|
| |
| | e porque não fazer o mesmo mas aqui com o ppl do gildot? poderiam haver certas diferenças ... além de ser especifico para o pessoal tuga :P
|
| |
