Jump to content

kicken

Gurus
  • Content Count

    3,739
  • Joined

  • Last visited

  • Days Won

    106

kicken last won the day on May 21

kicken had the most liked content!

Community Reputation

536 Excellent

2 Followers

About kicken

  • Rank
    Wiser? Not exactly.

Contact Methods

  • Website URL
    http://aoeex.com/

Profile Information

  • Gender
    Male
  • Location
    Bonita, FL
  • Age
    33

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The logic $number != 101 OR $number != 102 is always true. Look at the conditions separately for various cases: Case 1) $number = 99 $number != 101 => true $number != 102 => true true || true => true Case 2) $number = 101 $number != 101 => false $number != 102 => true false || true => true Case 3) $number = 102 $number != 101 => true $number != 102 => false true || false => true What you want is AND, not OR. Case 1) $number = 99 $number != 101 => true $number != 102 => true true && true => true Case 2) $number = 101 $number != 101 => false $number != 102 => true false && true => false Case 3) $number = 102 $number != 101 => true $number != 102 => false true && false => false
  2. I've more or less stopped typing tags in at this point. It's inconvenient to not be able to but what ya gonna do. For longer posts I usually compose them in notepad then when done move them over to the text area and insert all the quotes/code blocks/formatting using the appropriate buttons. More work, but make the post look right. I miss the old text-only editor still.
  3. PHP saying there is a syntax error on line X doesn't necessarily mean that the error is actually on line X. It could in fact be anywhere from line 1 through X. The line PHP reports is just where PHP finally realized there is a problem. With issues such as missing quotation marks or missing closing braces PHP will be able to continue parsing the source for quite a while before realizing something is amiss. Most of the time, the line number reported gets you close, but if nothing appears wrong there you need to start back tracking until you figure it out.
  4. The order you want depends mostly on how you'll be using the index in your queries. I'd venture that in an order system you're most likely going to be joining orders to the details then to the products to generate invoices and such, which would have queries like: select * from orders o inner join order_details od on od.order_id=o.id inner join products p on p.id=od.product_id A query such as that would want your UK defined as (order_id,product_id). With that order the UK can be used to enforce your foreign key relationship on the order_id column and be used to speed up the join between the orders and order_details tables. If on the other hand you were doing a query based on products, such as to find popular products you might do queries like: select * from products p inner join order_details od on od.product_id=p.id For that kind of query you might consider the (product_id,order_id) order so you could use the UK to handle your product_id foreign key and the join to the products table. In either case, assuming both order_id and product_id are foreign keys then your UK can satisfy the index requirement for one of them and the other would need it's own index. Neither order is particularly bad or good in this situation as you need at least two indexes anyway. In such a table design you don't necessarily even need your ID column so you could just make your PRIMARY KEY be (order_id, product_id). Some people prefer always having a auto_increment primary key but in the scenario proposed it's not necessary and could be removed. More indexes mean more index management and disk space usage. That can potentially lead to slower performance when inserting/updating/deleting data, but wouldn't have any significant impact on selects. As such, you should try and limit your indexes to only those that you absolutely need to make your system function well. Until your system grows to a very large scale (millions of rows), it's unlikely you'd notice any problems from extra indexes though. There's no efficiency to be gained from having the separate PK and UK there as far as I am aware. A single multi-column primary key would be just as effective and save an index.
  5. It is in the case you setup in your original post. I know you had some other thread ended up talking about this whole object-oriented sub/super type thing but I didn't really pay attention to it so am unfamiliar with the details. Looking at just this thread in it's own context the answer that your unique constraint is unnecessary is factual. In your original post you show that ID is a primary key (signaled by the (pk) bit). By definition, a primary key is unique across the table which means it's the only thing needed to find any particular row in the table when doing a join or a search. As a result, including it in another unique index is mostly pointless as discussed before. Your link describes a somewhat different situation from what you originally posted. The unique constraint is there because it's necessary for a foreign key in another table, and that foreign key has more to do with enforcing row types than to support joining of tables (as implied in your question "..using that as a join to another table"). In all the tables in that stack exchange example, the veh_id column is the only thing strictly necessary for the DB to handle all the joins and link the tables together. The rest of the columns have to do with your type enforcement. I'm not sure why they used separate primary/unique keys, I think the whole thing could have been done by making a single multi-column primary key which might make the whole thing easier to understand. Because indexes work essentially left-to-right, so if you want to take advantage of a column being part of an index, it either has to be the left-most column of the index, or you also have to specify all the columns prior to it. If you define the order as (id, product_type_code) then you can't use that index to search for a product_type_code unless you also specify an ID (and since ID is unique, that makes the product_type_code mostly useless). However if you define the order as (product_type_code, id) then you can search for a product_type_code using that index and get all the matching ID's as a result. Applying this to your stack exchange example, it also means that you in fact cannot double-dip on your indexes and will need to create extra ones to support your foreign key definitions. Because veh_id is the value that ties all the tables together, you want it to be the first value in your unique / primary key constraint. As a result the veh_type_code will need it's own index to support that foreign key definition.
  6. The foreign key constraint needs a suitable index on the column, but it doesn't need to be an index dedicated to that column. So yes, you can double up your unique index if you create it properly. In order to re-use it, the foreign key column must be the first column in the index, so when you create it you want to do CONSTRAINT UQ_blah UNIQUE (product_type_code, id) and not CONSTRAINT UQ_blah UNIQUE (id, product_type_code). As mentioned though, in the scenario you laid out, the unique constraint is entirely unnecessary as your ID column is already unique by virtue of being the primary key so you'd just make a simple index on the product_type_code column. In a scenario where Id wasn't a primary key and a unique constraint was necessary then you could double-dip like that.
  7. The MySQL manual says: So it would seem you are stuck in that case. I generally use SQL Server these days which does allow the name to be specified and I use PK_<tablename>. I use a similar format for other constraints, just with different prefixes/suffixes. How you name them doesn't really matter though, many people just use auto-generated names and it works just fine.
  8. kicken

    Nested UK's

    If column 3 is unique across the entire table, then MySQL only has to search column 3 using it's unique index to find the one matching row on your join. Column 1 and column 2 become essentially redundant and you could just exclude them entirely.
  9. kicken

    Nested UK's

    If that column by itself is unique, then any set of columns that includes it will automatically be unique, there's no real need for an extra key.
  10. Don't be afraid of having to re-factor things in the future. You don't have to get the perfect layout from the get go. I find that many times even when I tried to plan for the future and design accordingly I'd usually miss something and end up doing some refactoring anyway. Best to just wait until you know what you need rather than guess at what you think you'll need. The book/component table structure sounds fine. If in the future you decide to split it up further you can. If in the future you decide to do pages/sections you could probably do so with relatively little changes to the tables.
  11. Aka, poor implementation. No JS is necessary to avoid loading the full sized version, you just link it separately. <a href="full-size.png"><img src="thumb.png"></a> I personally wouldn't, no. I have a dual-screen desktop so I'd open the book on one screen and Photoshop on the other. In the particular case of Photoshop it seems unlikely in general anyway to me. The person would need a desktop to run Photoshop on anyway so if they were trying to follow along and learn why not just open it in a browser on the desktop. Right, but if you're loading appropriately sized images then 30 images loading shouldn't really be a big deal. A full-size 1920x1080 scaled down to roughly phone-screen sized images should only be around 20-100k in size. 100k * 30 = ~3MB. 3MB on an average mobile connection would take all of 1 second to download. It's basically illegible sure, but that's where the previous point of having mobile-friendly versions comes in. Alternatively, link the illegible version to a full-sized version they can load and zoom/pan around on demand. A lot of people do things on mobile now, so it's certainly worth considering that market, but in my experience people still acknowledge when something isn't really a good fit for mobile and will move to a desktop/tablet in those scenarios (if possible). I have a friend that does practically everything from her phone mainly because for a long time she had nothing else. From time to time however she will come by to use my computer for things because they are just not mobile-friendly tasks and she recognizes that. Most people I know are still rational about what is and isn't a good fit for mobile, so I think your fear of everyone demanding a refund because your site isn't 100% mobile friendly is irrational. Sure, there may be some because people can be dicks but that's part of business. If your books deal with teaching software and that software is primarily a desktop thing I'd wager most people will interact with the site from a desktop. I'd make some considerations for mobile (responsive layout, smaller images) for those who might want to read some on their phone while away from a desktop (ie, commuting) but wouldn't spend a ton of time up front trying to make that experience perfect. I'd push that until later when everything else is up and running and more time is available to focus on that and/or real customers start requesting it.
  12. If you think the entire screen is necessary to understand the content then so be it and the user's choice of device isn't really your concern. The user can either choose to struggle on their device or move to a more capable device. Your focus needs to be in determining if the entire screen truly is necessary, or if it's just a "nice to have". For a desktop user, it might be nice to see the whole thing, but maybe they only really need to see the top left corner and bottom right corner and you can cut out all the middle stuff. Something I do frequently when creating screenshots it to resize my windows so they are as small as possible to remove wasted empty space then take the screenshot. If you can't per-emptively make the window smaller, cut the middle part later and leave some jagged edges indicating it was cropped.
  13. That's just due to a poor implementation or a slow connection it sounds like. I've had larger galleries load in much less time. If you properly thumbnail your images (ie, not just set the width/height in the html/css) then things should load fairly easily and quickly on any sort of modern connection. Then you link those thumbnails to the full size version so that it will only load if the user clicks on it. In any event, this thread sounds to me like a case of premature optimization. You're worried about performance issues without having any real data showing these is a problem to begin with. 10-12 images and whatever text is pretty much nothing for the modern web for most people on the desktop. On mobile, size can still be an issue, so it can help to reduce the image load. Start by just employing one of the lazy-loading libraries and then see how things work before investing more time into something else more complicated. You're already worried about images being illegible on mobile, so test it and see. If they are then maybe you need to create new images or re-write the text to accommodate mobile which might make the loading problem moot. That depends a lot on how the screenshot is composed. If you're taking a screen shot of a full 1920x1080 monitor to show the pivot table sidebar then yea, it'll be hard to read. If you crop that to just the sidebar and eliminate wasted space to show the specific options however then there shouldn't be an issue. This is something that the <picture> element mentioned by maxxed a few times could help with. Aside from just different resolution images for different devices, you could have entirely different images. Maybe the desktop users get the full 1920x1080 shot because it's similar to what they might see, but mobile users get the cropped version so the pivot table options are legible.
  14. Exceptions are different than errors, and there's a separate function to install a handler for them: set_exception_handler. That kind of handling is only for doing something like logging the error or whatever however, you can't use it to ignore the exception and continue. If you want your script to continue executing despite the exception, then you need to catch it with a try/catch block and handle it appropriately there.
  15. You want the Modulo operator.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.