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
TEXTvalues through aBEFORE INSERTtrigger. 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.