@Hamniba 就是爬下来处理成不同大小之后优化保存 ...

压力主要来自压缩图片 ... 应付访问的压力完全不大 ... 开支也在能接受的范围内 ...

给家里备了两台 ... 一台 iPhone 4S 一台 Mi3 ... 两台加起来不到一千块 ... 用的都很好 ...

谈额桑海女帮友 ... 侬桑海矮屋会的老快好额 ...

我知道我说再多楼主也听不进去 ... 简单陈列几个事实好了 ... 浪费五铜币就浪费了吧 ...

第一 ... 我有辆跑车 ... 买它的时候我每月可支配资金就只有一万出头 ...

第二 ... 我问了下 ... 除非吃家里住家里 ... 否则你买不起新的 A6 ...

第三 ... 二手的 A6 你足够负担 ... 如果是那种手动挡的老 A6 你甚至很轻松就可以负担 ...

第四 ... 想买新 A6 请提升自己 ... 光在这里念叨你永远也买不起 ...

第五 ... 如果你挂了银行会收回你的车 ... 在这件事情上你的家人不会有任何损失 ...

既然今天已经莫名的回了几个帖子了就不在乎再多回几个了 ...

首先我不推荐一个六岁的孩子学任何语言 ... 包括写代码的游戏也不行 ...

还没上小学二十六个字母都认不齐 ... 这些事情太难为他了 ... 还是循序渐进的好 ...

回想了一下我小时候的编程入门 ... 大概是汉诺塔九连环一类的古典游戏开始的 ...

现在时代发展了也出现了很多寓教于乐的东西 ... 比如 http://lightbot.com/ ...

这个游戏涉及了程序的基本流程和部分编程思想 ... 我相当推荐用这个入门 ...

如果玩过游戏之后还对程序有兴趣的话 ... 可以让他用 LOGO 接触语言或者 Scratch 完成作品 ...

总之不要教给他过多的规则 ... 告诉他每个东西是干什么用的就好 ...

我小学时候用 LOGO 和 GWBASIC 都拿过奖 ... 初中 QBasic / PASCAL / TurboC 都进过决赛 ...

现在回想起当时写程序的感觉 ... 和现在写程序完完全全不同 ... 没有任何束缚就是开心的写 ...

现在随着年龄增长 ... 小时候的灵气渐渐消失殆尽了 ... 再也找不回来 ...

小孩子看到的世界和我们看到的世界真的是不一样的 ... 千万不要让他太快长大 ...

@wujunze 我是真没见过假的二锅头 ... 随便一个大点的超市买的都是真的 ...

不过如果你不放心又有闲时间的话可以跑趟顺义 ...

拎着酒瓶子在牛栏山酒厂前面自拍一张 ... 送酒的时候连着照片一起展示 ... 效果绝对好 ...

一个提示 ... Redis 的所有命令都是原子性的 ... 其中包括 INCRBY ...

今天净碰到商城相关的问题是为什么 ...

@neetrorschach (<ゝω·)☆ 绮罗星～ ☆ kira

嘛其实我也是手贱啦 ... 本来都决定了不谈论技术的 ...

结果看到这种对口的问题还是忍不住啊 ...

@passion336699 你怎么用代码控制 ..? 一种三色手机只有白色有货用户下黑色单你能过 ..?

以及我顺便提一句 ... URL 和规格无关代表用户点击进来必须手动勾选规格或者只能买默认 ...

如果不确定的话还是问问你们产品吧 ... 省得做完了再改 ...

@passion336699 你可以同时实现 1 和 2 ... 不想 reload 的话一次读完前端控制切换就好 ...

论方便实现的话哪种都方便 ... 但这两种方式其实并不仅仅是刷不刷新页面的区别 ...

你还是没 Get 到点 ... 这两种模式最核心的区别在于能否直接通过 URL 选中商品的规格 ...

所以具体选择用哪种还是要看你的业务场景 ... 没办法一概而论的 ...

@naffan @kanezeng 对于简单的情况来说写在 Item 表里也没什么问题 ...

但实际的库存远不是一个数字就能简单解决的 ... 记录各大区各仓库的库存情况就不止一张表了 ...

加上出入退库记录 ... 货物调配 ... 库耗控制 ... 呆滞警报等等杂七杂八的事情 ...

再算上厂家直发的部分 ... 总之库存这两个字的复杂程度绝对超乎你想象 ...

@naffan 你理解成商品 id 就可以 ... fakeid 和自增 id 是一对一的关系 ... 用于数据传输 ...

给你做了个例子 ... 见下 ...

mysql> SELECT * FROM `ware_product`;
+----+----------+--------------+------------------------------+--------+
| id | category | name | attributes | status |
+----+----------+--------------+------------------------------+--------+
| 1 | 329475 | 某种手机 | ["网络","颜色","存储"] | 1 |
| 2 | 131329 | 某种衣服 | ["尺码","颜色"] | 1 |
+----+----------+--------------+------------------------------+--------+
2 rows in set (0.00 sec)

mysql> SELECT * FROM `ware_item`;
+----+-----+--------+--------------+------------------------+---------+-------+--------+
| id | pid | fakeid | name | attributes | price | stock | status |
+----+-----+--------+--------------+------------------------+---------+-------+--------+
| 1 | 1 | 583701 | NULL | ["电信","白","16G"] | 1999.00 | NULL | 1 |
| 2 | 1 | 583702 | NULL | ["电信","黑","16G"] | 1999.00 | NULL | 1 |
| 3 | 1 | 583703 | 最后五台 | ["移动","黑","64G"] | 1999.00 | 5 | 1 |
| 4 | 2 | 241351 | NULL | ["M","红"] | 128.00 | NULL | 1 |
+----+-----+--------+--------------+------------------------+---------+-------+--------+
4 rows in set (0.00 sec)

这是个简单的模型 ... 我把没用的东西比如副标题推荐语图片角标等等都去了 ...

库存也只是写个意思 ... 实际上库存不在这里 ...

Product 表是抽象的产品表 ... 当前产品下的所有 SKU 的共有属性保存在这里 ...

Item 表是具体的详情表 ... 所有涉及交易的实体都存在这里 ...

用户可感知的只有 item.fakeid ... 通过 fakeid 取得其他所有数据 ...

每个 SKU 拥有独立的 id ... 传值的时候传这一个 id 就可以 ...

比如一台手机有三网三色两种存储 ... 在数据库里就有 18 条记录 ...

我近两年时间写了三套商城了 ... 我可以很负责任的说如果按照你这么建表后患无穷 ...

/t/98535#r_939468 ... 两年前的回复了 ... 供参考 ...

还有些小零食上面那个帖子没提到 ... 排岔儿牛舌饼什么的 ...

上次我拎了一口袋大家分而食之反响不错 ...

以及楼上提到的请尊兔儿爷也是个不错的主意 ... 中不中秋的现在也不讲究了 ...