0

I need to store 100 URL addresses + 100 text labels. I would like to have a default value for both. The problem that I have run into is that I have set the URL fields as VARCHAR, length = 1024 and the text labels as VARCHAR, length = 30. while building my table I've encountered the error, "Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs"

How else might I go about accomplishing my objective? I can't use TEXT b/c it does not allow me to store a default value for that field.

4
  • You could implement "default" TEXT values through a BEFORE INSERT trigger. But do you really need this denormalised schema? Why not have a separate table, each record in which relates a single URL and text label to a record in this existing table? You could then have 100 records in that new table for each record in the existing table, if so desired. Commented Apr 27, 2013 at 23:14
  • "64KiB in a single row" - I don't understand that. Doesn't the VARCHAR, length = 1024 mean that I can store a string that is 1024 characters long? (Please excuse me if I'm asking a dumb question!) Commented Apr 27, 2013 at 23:18
  • @LyleCrumbstorm . . . apparently there are 100 such fields in each reocrd. Commented Apr 27, 2013 at 23:20
  • Gordon - Yes, 100 fields in each record is correct. Each person who registers is assigned 100 URL fields & 100 Text fields. While I am new to this, I sure was cranking along until I hit this bump! Commented Apr 27, 2013 at 23:27

2 Answers 2

3

Having 100 fields in a record for this is, bluntly, wrong. Don't do that.

Instead make a new table with it's own primary and a foreign key linking back to the parent table, and each of the rows in this table can hold the URL and label. Then you can have your application ensure that no more than 100 rows per parent are stored in this table.

Yea, the idiom is quite different from what you have now, but it's much, much better.

Edit for comment:

SQL best models "collections of things" as rows in tables. The classic discussion point in a database model is when you're talking about a specific piece of data. The question inevitably boils down to "is there going to be 1 of these items, or many".

If there is just one item, then this best modeled as a field in a row in a table. If there are many, then these items are best modeled as individual rows in a table.

Right now you may have something like:

create table user { id number primary key not null, firstName varchar(30), lastName varchar(30), url1 varchar(1024), url1label varchar(30), url2 varchar(1024), url2label varchar(30), url3 varchar(1024), url3label varchar(30), url4 varchar(1024), url4label varchar(30) } 

Having repeating fields like this is a "bad" pattern in SQL databases, as a rule. All rules have exception, but as a general rule, when just starting out, it's a bad idea. At a minimum you're taking up space for all of these url fields, no matter how many they actually use.

Second, from a SQL point of view, these numerous, repeated fields are extremely difficult to work with. For example, you can't easily query the database to see if anyone has http://google.com as a url. You would have to have something awful like:

select * from user where url1 = "http://google.com" or url2 = "http://google.com" ... 

So, rather a better model would be something like:

create table user { id number primary key not null, firstName varchar(30), lastName varchar(30), } create table urls { id number primary key not null, user_id number not null references user(id), url varchar(1024), label varchar(30) } 

Here, each url row has it's own primary key, and a reference to the user that the url belongs to via user_id.

If you want to get all of the urls for a user you would do:

select * from urls where user_id = 123 

Now, the database offers no limitation to how many urls a user can hold. A user can have 0, or 1, or a million. The database will not enforce any kind of limit here. If you want to limit them to 100 urls, then your application will need to do that itself.

But hopefully you can see that if one user has 2 urls, they will have only 2 rows in the urls table, whereas a user with 50 urls will have 50 rows.

For you other fields that you only have 1 of (like first name and last name) those could all be fields on the primary user table.

But fields that repeat, most likely, are better represented as their own table with a foreign key to the parent

Sign up to request clarification or add additional context in comments.

2 Comments

I'm researching each answer here all over the Internet in hopes of not embarrassing myself any further but it's too late for that anyway... right now, each user that registers is given a unique id w/in the DB and a whole list of fields is assigned to them - about 130 in all. each of these fields needs to have a default value. I must not clearly understand the concept of a table or the difference between rows and fields. why can't I just store info for 100+ fields w/in this table?
that's awesome of you to type out this detailed explanation! your idea of what my current database looks like is spot on. (how have you seen my project already?!) I will come back to this solution once I understand things a little more clearly and I will laugh at the inefficient, uneducated way I have jerry-rigged things. in the meantime, thanks again!
0

Is okey having a fields varchar of length 1024 and another one of length 30. Proof: http://sqlfiddle.com/#!2/8d4f7/1024

As a warkaround at your issue, you can use TEXT (which is recomanded probably for better storage?).

But, the problem is that the total length of your row table must not be greater than 65532.

References: http://www.pythian.com/blog/text-vs-varchar/

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.