Re: [sqlite] mysql to sqlite

SQLite doesn't enforce types, but it does accept them. They're documented at https://www.sqlite.org/datatype3.html Basically, you want INTEGER and TEXT. There's no date type. I recommend storing those as epoch integer, or in ISO text format, so that they're easy to parse and sort correctly.

[sqlite] mysql to sqlite

Hello, I have some tables in mysql with the following data types: smallint text varchar date I don't know sqlite, What are corresponding above data types in sqlite? --Regards Mohsen ___ sqlite-users mailing list

Re: [sqlite] MySQL vs. SQLite

I asked that before because Oracle do this. It notify the developer and ask if we want to create that transient index as materialized. I didn't see this working but I know this by a friend. -- Atenciosamente/Regards, Israel Lins Albuquerque Desenvolvimento/Development Polibrás Brasil

Re: [sqlite] MySQL vs. SQLite

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > You might be interested in NoSQL, or in databases which have no schema: every > piece of information is a property of an object. I do happen to use them pretty intensively, especially MongoDB, so here are some things they do differently: There is

Re: [sqlite] MySQL vs. SQLite

Simon Slavin wrote: > On 2 Jun 2010, at 1:14am, Darren Duncan wrote: > >> What are some examples of the proposed SQL replacements that do this? > > You might be interested in NoSQL, or in databases which have no schema: every > piece of information is a property of an object. Please note: I am

Re: [sqlite] MySQL vs. SQLite

On 2 Jun 2010, at 1:14am, Darren Duncan wrote: > What are some examples of the proposed SQL replacements that do this? You might be interested in NoSQL, or in databases which have no schema: every piece of information is a property of an object. Please note: I am not recommending these

Re: [sqlite] MySQL vs. SQLite

Simon Slavin wrote: > On 1 Jun 2010, at 11:59pm, Scott Hess wrote: >> Well, really, what you want is "SQLite, for this table, I want to these >> SELECT and UPDATE statements in this ratio, what indices would be ideal?" > > That's often handled with smart caching. The cache system notes down how

Re: [sqlite] MySQL vs. SQLite

On 1 Jun 2010, at 11:59pm, Scott Hess wrote: > Well, really, what you want is "SQLite, for this table, I want to > these SELECT and UPDATE statements in this ratio, what indices would > be ideal?" That's often handled with smart caching. The cache system notes down how often each item is hit,

Re: [sqlite] MySQL vs. SQLite

On Tue, Jun 1, 2010 at 2:37 PM, Simon Slavin wrote: > On 1 Jun 2010, at 7:11pm, Israel Lins Albuquerque wrote: >> About that future release functionality. Will be possible to know whats >> temporary index are created? >> Using that information will be easy to know what

Re: [sqlite] MySQL vs. SQLite

On 1 Jun 2010, at 7:11pm, Israel Lins Albuquerque wrote: > About that future release functionality. Will be possible to know whats > temporary index are created? > Using that information will be easy to know what indexes we need create to > increase perfomance, > don't giving chance to

Re: [sqlite] MySQL vs. SQLite

On Tue, Jun 01, 2010 at 02:13:06PM -0400, Richard Hipp scratched on the wall: > On Tue, Jun 1, 2010 at 2:09 PM, Israel Lins Albuquerque < > israel...@polibrasnet.com.br> wrote: > > > About that future release functionality. Will be possible to know whats > > temporary index are created? > > Using

Re: [sqlite] MySQL vs. SQLite

On Tue, Jun 1, 2010 at 2:09 PM, Israel Lins Albuquerque < israel...@polibrasnet.com.br> wrote: > > > About that future release functionality. Will be possible to know whats > temporary index are created? > Using that information will be easy to know what indexes we need create to > increase

Re: [sqlite] MySQL vs. SQLite

About that future release functionality. Will be possible to know whats temporary index are created? Using that information will be easy to know what indexes we need create to increase perfomance, don't giving chance to sqlite create that indexes! -- Regards/Atenciosamente, Israel Lins

Re: [sqlite] MySQL vs. SQLite

- Mensagem original - De: "Richard Hipp" <d...@sqlite.org> Para: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> Enviadas: Segunda-feira, 31 de Maio de 2010 20:56:33 Assunto: Re: [sqlite] MySQL vs. SQLite On Mon, May 31, 201

Re: [sqlite] MySQL vs. SQLite

ices are normally only created for multi-way joins or perhaps for subqueries. This automatic-indexing feature is new. It has only been in the source tree since early April and has not yet appeared in a released version of SQLite. > > MySQL and SQLite are both excellent example

[sqlite] MySQL vs. SQLite

mory to be used for caching, and a persistent server process. And it would require a thorough rewrite of SQLite which would then no longer be practical for small fast embedded devices. MySQL and SQLite are both excellent examples of their craft, but they're suitable for different situations.

RE: [sqlite] mySQL to SQLite conversion question

D] Subject: [sqlite] mySQL to SQLite conversion question I see that the auto_increment keyword is not supported by SQLite: addressid bigint(20) unsigned NOT NULL auto_increment, . . . PRIMARY KEY (addressid) I understand that I ha

[sqlite] mySQL to SQLite conversion question

I see that the auto_increment keyword is not supported by SQLite: addressid bigint(20) unsigned NOT NULL auto_increment, . . . PRIMARY KEY (addressid) I understand that I have to move the 'unsigned' keyword (before 'bigint') but I do

[sqlite] mysql to sqlite and linebreaks (\n)

Hi, i've a problem with linebreaks in sqlite. my mysqldump has some \n for linebreaks, but sqlite do not undestand this. how can i escape the linebreak? THX Sascha Wojewsky