I am currently using Postgres, however, I would like to use standard SQL types for my columns, for portability reasons.
I am attempting to do my modelling in Visual Paradigm Version 14.2 (Build sp1_20180201), under an evaluation license.
I can create an E-R diagram, and when I generate the SQL, Visual Paradigm asks me to select a database configuration before it can do this. So I selected Postgres, but now it converts all my standard types into Postgres specific types! For example, every BIGINT becomes an int8, both in the generated SQL code and the diagram.
Now when I edit the column in the diagram, I can select BIGINT again, but it now appears in italics in the drop down box, and when I save changes to the column, it is int8 again.
How do I successfully generate standard SQL code from an E-R diagram in Visual Paradigm?
Once you specified the database type then the columns will automatically changed to the compatible types for that database. In PostgreSQL the bigint is aliased in int8 and that's why your columns are show in int8 even you manually changed back to bigint. You can override this by defining bigint in User Type field of column's specification dialog. Detailed steps can be found at https://knowhow.visual-paradigm.com/database-design/custom-column-types/
Related
I'm new to both Visual Paradigm and ERD. I created an entity, but am a bit lost what some of the notation is. I'm not sure what the large 'N' is, or the number 10 associated with the ID integer (both were autogenerated when creating a column). Any help would be great, I can't seem to find this in the documentation.
The "N" indicate the column is nullable or not.
The column type (integer or number) is subject to the target database specified for your project (under Tools > DB > Database Configuration). For example, by specify project target DB as Oracle then the columns with integer(10) will automatically change to number(10).
You can mark a column as primary key by simply adding "+" sign in front of the column name while in-line editing the column in ERD.
You can find the general ERD modeling tips for Visual Paradigm at https://www.visual-paradigm.com/support/documents/vpuserguide/3563/3564/85375_drawingentit.html
I have understood the solution for changing the column type from string to text while using postgresql and rails 3.2 provided here. I have also implemented it. But when I rollback this migration, it fails with "PG::StringDataRightTruncation: ERROR: value too long" error. How should we tackle this problem?
You have new values that're too long for the old type. PostgreSQL would have to throw away data to change to varchar(255) if the values are longer than 255 chars. It refuses to do so because it won't cause data loss without being told very specifically to do so.
If you don't mind truncating these long values, permanently and unrecoverably discarding data, you can use the USING clause of ALTER COLUMN ... TYPE. This is the same approach used when converting string columns to integer.
ALTER TABLE mytable
ALTER COLUMN mycolumn
TYPE varchar(255)
USING (substring(mycolumn from 1 for 255));
I don't think there is any way to express this symmetrically in a Rails migration; you will need separate clauses for the up- and down- migrations, with the up-migration being a simple:
ALTER TABLE mytable
ALTER COLUMN mycolumn
TYPE text;
Frankly though, I think it's a terrible idea to do this in a migration. The migration should fail. This action should require administrator intervention to UPDATE the columns that have data that is too long, then run the migration.
Normally to create/alter a table in database I use migrations (manually run rake db:migrate) and then in my code I use ActiveRecord. This is very cool as I don't have to worry about representation of the data in db and about a specific kind of db (sqlserver, pg or other).
But now a customer wants to be able to create "things" on-fly himself like, say, he starts selling computers, so he wants to an interface where he can dynamically create an object "computer" with properties like "Name, RAM, HD, ...". It seems to be quite natural to create a separate table in db with all these fields. But how can I do that in RoR and keep all these nice things about ActiveRecord?
Please suggest.
The usual way is to do exactly the opposite:
Have a table for object types
Have a table for field names for each object type
Have a very big table with all the custom attributes for each object of any type
This is called EAV (Entity-attribute-value model, see http://en.wikipedia.org/wiki/Entity-attribute-value_model). And it scales pretty bad.
Alternatively, you can use a store text column instead of the big EAV table (see http://api.rubyonrails.org/classes/ActiveRecord/Store.html) so you don't have to make those difficult attribute retrievals, typical of EAV. You still need to store somewhere the "object types" definitions, so the expected fields etc are available when building forms and tables.
The problem with this approach is that you are not able to query (where/join/select) on those attributes because they are not columns. There are a number of solutions to that:
Don't do filtering on those attributes (meh...)
Have an external search server that's able to do faceted search
(as #Amar correctly says) Use a document database
Use postgreSQL and use hstore instead of a simple serialized column.
NoSQL database(Document Database Mongodb,CouchDB) can be best fit for this or use redis. As per my thoughts you can use Vertical Table concept Try to run Rails 2.x Demo of application for MySQL.
You can try with Mongodb, check if this is needed.
I'm working with Dynamics ax 2012.
I'm finding a way to create foreign key with dynamics ax.
I try to create new -> relation -> new -> foreignkey -> primarykey based
I successfully created this relation but when I look the database in SQLSERVER2008 i think ((the relation)) the foreign key is not created !
And what about the primary key !! what can i do to create my personal key other then "RecId" !!
If one day i want to import a database created with SQLSERVER2008 to Dynamics AX will it be possible ? and how do I do that ?
Sorry but table relations are for the benefit of the AX environment, it is not synced to the database. Basically only fields and indexes are synced.
Can you make an AX database from an SQL database?
It probably could be done using a good deal of X++ programming doing ODBC reads from the source database meta tables. I don't know if anyone have tried it, but I doubt it.
You are most likely better off by a total database redesign, as the AX data dictionary contains more information than the SQL database.
How would you convert an SQL Database to use Valid Time State Tables and Date Effective Data?
Using RoR 2.3.8.
I have two models. It's strange that when I typed text and saved in Model A, it shows the exact text, but when I do this in Model B, it shows ???. It's most likely one supports UTF-8 but another doesn't. The thing is, I don't remember me setting any on either. What can I do to fix this?
Using Mac OS 10.6.7, Chrome
MySQL and other database engines set the encoding used for text on several levels: server, database, table and column. Generally the defaults are applied from the top down, from server to database, database to table and so forth, but they can be customized at any given point as required. Sometimes this happens inadvertently and can cause issues.
One way to know what encoding is currently active is to use a client like Sequel Pro which will expose this information to you, or to investigate using the mysql command line tool:
SHOW CREATE DATABASE example;
You get a response that contains something like this:
CREATE DATABASE `example` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci */
In this case it's a UTF-8 table with UTF-8 UNICODE collation. The encoding defines how thae data is stored and the collation defines how to handle sorting and case conversion.
Investigating further you can examine the table and columns:
SHOW CREATE TABLE example;
This gives a lot more detail, something like this:
CREATE TABLE `example` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`email` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
UNIQUE KEY `index_example_on_email` (`email`)
) ENGINE=InnoDB AUTO_INCREMENT=29 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
In this case the table itself is defaulting to UTF-8 and the email column is likewise flagged. You may have a column that's different.
If you need to alter the encoding or collation you can use the ALTER TABLE statement to effect this.